会员提供者使用还是不使用？

Question

我正在开发一个使用 Facebook 的网站。现在为了管理用户，我想到了使用MembershipProvider 并选择开发一个自定义会员提供程序。我的问题是我的数据库模式与标准成员模式不匹配，并且提供的用于覆盖的函数采用的参数与我预期的不同。例如，会员使用用户名作为用户名登录。但我必须使用用户电子邮件 ID 作为用户名。此外，它的搜索功能基于使用用户名作为搜索方式，但我希望它通过 UserID 进行搜索。用户插入、删除、修改也是如此。

在添加新用户的同时，我还想保存用户的 facebook 相关数据...比如 UID 和访问令牌。

编辑

这只是一个想法，在参数中强制传递我的值然后在我的代码中处理它们是否可行？

更新

我发现 Create user 方法中有一个object providerUserKey 参数。在 MSDN 文档中，我发现它用于为每个新行传递一个唯一键，如 GUID。但是在我的数据库中，我已经为新行的 UID 提供了规定。所以我应该使用这个 extra 参数通过这个参数将我的自定义数据作为对象传递并在我的自定义提供程序代码中处理它。

Answer 1

如果在滚动您自己的身份验证/登录或使用会员资格和编码映射层之间进行选择，那么我肯定会选择后者，您始终可以在会员资格为您提供的基础上进行构建，如果不是通过 API，那么使用数据库表直接。

如果你自己动手，你不可避免地会弄错身份验证并在以后付出代价。

作为替代方案，您可能想查看OpenID authentication，即查看此 SO 线程：OpenID authentication in ASP.NET?

编辑：

我认为您不需要自定义会员资格提供程序。在我过去完成的一个项目中，在与 ASP.NET Membership 集成之前，我们有自己的用户管理。除了将 SQL 成员资格表添加到我们的数据库之外，我们所要做的就是提供我们的用户（当时有一个常规的 bigint 作为键）和成员资格用户 GUID 之间的映射。通过这种映射，您还可以保存所有与 Facebook 相关的数据（只是与会员用户的 FK 关系）

除此之外，我确实认为会员资格已经允许使用电子邮件地址登录，所以我认为您不会遇到太多麻烦。