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