我在一个由开发人员组成的小团队中工作，对于完成许多核心任务的最佳方法没有达成共识，其中一个是成员(member)提供者。现在我无法确定这是否与缺乏对替代思维方式或足够规模的项目的接触以保证进行重大调查有关。
我多年来一直是 .net 网络开发人员(在 php 和 asp 经典之前)，通常在开发应用程序时，我回避使用内置的 .net SqlMembershipProvider 主要是因为它对于我的需求来说似乎过于复杂，其次是因为我只能想象这样一个复杂的数据模型可能会影响性能。
通常，我使用在相当简单的 user -> user roles <- roles 类型架构上运行的自定义成员资格和角色提供程序。根据相关应用程序的需要，我维护标准的成员(member)提供商功能，例如帐户恢复、个人资料详细信息、登录帐户锁定失败、 secret 问题等，例如 AD 安全应用程序几乎没有附加功能，面向公众的应用程序通常具有商场。这也意味着任何需要存储过程来咀嚼用户数据的任务应该很容易编写并且执行得很好。直接的 SQL 命令、良好的索引和简单的数据模型产生了一个高性能、可扩展的解决方案，该解决方案应该需要更改我可以完全控制根据需要进行更改，我认为这是非常宝贵的。
根据您的经验，您会说这是一种过时的方法吗？您是否遇到过内置提供程序的可扩展性问题？您通常采用什么方法以及在什么情况下使用？
谢谢
最佳答案
除非您特别确定了不这样做的令人信服的理由，否则我建议您从 SQLMembershipProvider 开始，并根据需要对其进行调整。
我们发现内置提供程序为我们提供了所有基础知识，而我们几乎没有做任何工作。开发一个好的安全结构有很多要素，很容易忘记其中一个，或者只是懒惰而不是在你自己滚动时以“正确”的方式实现其中一个。想到了诸如通过电子邮件加盐密码和密码重置之类的事情。
当然，SQLMembershipProvider 不是 Elixir 。我们在一些情况下需要对身份验证做一些更复杂的事情。但是我们能够通过扩展 SQLMembershipProvider 而不是替换它来解决这些问题。有关更多详细信息，请参阅我在 What is a good way to extend .Net Membership to track user logins 上的回答。
我们没有注意到 SQLMembershipProvider 引起的任何重大性能问题，所以我认为打性能牌是没有根据的。毕竟，您的用户通常会花多少时间登录您的系统？如果您的所有页面加载速度都很快，那么根据您将提高性能的想法(可能是错误的)编写您自己的所有代码是没有任何理由的。这就是我们一直在读的可怕的“过早优化”。
Roles 框架对于我们的需求来说过于简单，所以我们根本不使用它。但它也没有妨碍。
而且，正如 Hogan 指出的那样，您更有可能找到已经熟悉内置提供程序工作方式的开发人员，这意味着他们将花费更少的时间来尝试找出您的架构，并且(希望)有更多的时间完成真正的工作。
关于.net - SqlMembershipProvider 与自定义解决方案，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5445260/