ASP.NET成员数据库与成员资格和用户数据库

Question

有没有理由说我不应该使用自定义成员资格提供程序将联系人和扩展数据添加到用户数据库？

为用户数据和成员资格数据保留单独的一对一表有什么好处？据我了解，常用的方法是保留单独的表。我认为为用户提供一个表以保持SQL语句简单并自定义代码成员资格提供者会更好。

Answer 1

成员身份背后的理念是它提供即插即用的通用会员解决方案。假设您要从Sql切换到ActiveDirctory，您只需要更改成员资格提供程序，一切正常。

只要您创建自定义提供程序，就可以执行任何操作。但是，为了将您的额外数据添加到成员资格表中，您将在成员资格界面之外执行此操作（因为API不包含它们的字段）。这意味着，您实际上是在丢弃Membership API。

我的建议是：a）按照预期使用会员资格，或者b）完全自己动手做事。不要试图将会员资格变成不适合的东西。

但是，编写自己的内容比起初想的要多得多，至少如果你想要安全并覆盖所有基础。

Answer 2

优点是分离关注点。通过将它们保存在单独的表中，您处于可以单独交换或修改成员资格数据存储的情况。但是，在对“灵活性”过于兴奋之前，请考虑应用程序的实际生命周期。权衡未来需要改变的可能性与实施自定义提供者的前期成本。

当我实现自定义成员资格提供程序时，更常见的是，我发现自己在某一点上实际上希望我刚刚推出了一个完全自定义的身份验证机制。一旦实现了提供程序接口，就不必通过“插入”其他提供程序基础结构来获得大量收益。对于简单的应用程序，我通常只是建议做最简单，最简单的工作。如果您尚未构建许多身份验证系统，则可能会发现实现自定义提供程序的过程。