.net SqlMembershipProvider与自定义解决方案

我在一个由开发人员组成的小团队中工作，对于执行一些核心任务的最佳方法没有达成共识，其中一个是成员资格提供者。现在我无法确定这是否与缺乏足够规模的替代思维方式或项目相关，以保证进行重大调查

我作为.net开发人员已经有很多年了（在php和asp经典版之前），通常在开发应用程序时，我会避免使用内置的.net

SqlMembershipProvider

，主要是因为它对于我的需求来说似乎过于复杂，第二，因为我只能想象这样一个复杂的数据模型可能会影响性能

---

通常，我使用一个定制的成员资格和角色提供程序，在一个相当简单的

用户->用户角色上运行。使用内置提供程序应该更易于维护和查找熟悉api的资源（在雇用程序员时）。
除非您明确指出了不这样做的原因，我建议您从SQLMembershipProvider开始，并根据需要对其进行调整

我们发现，内置提供商提供了我们所有的基础知识，而我们几乎没有做任何工作。开发一个好的安全结构有很多因素，很容易忘记其中的一个，或者只是变得懒惰，在自己开发时没有以“正确”的方式实现一个。我想到了一些事情，比如盐渍密码和通过电子邮件重置密码

当然，SQLMembershipProvider不是灵丹妙药。我们遇到过一些情况，需要对身份验证执行更复杂的操作。但是我们仅仅通过扩展SQLMembershipProvider而不是替换它就能够解决这些问题。有关更多详细信息，请参阅我的答案

我们没有注意到SQLMembershipProvider带来的任何重大性能问题，因此我认为打性能牌是没有道理的。毕竟，您的用户通常花多少时间登录到您的系统？如果您的所有页面都加载得很快，那么在（可能是错误的）您将提高性能的想法下编写所有您自己的代码就没有真正的理由了。这就是我们一直在读的可怕的“过早优化”

角色框架对于我们的需求来说过于简单，所以我们根本不使用它。但它也没有成为阻碍

而且，正如Hogan所指出的，您更有可能找到已经熟悉内置提供程序工作方式的开发人员，这意味着他们将花更少的时间尝试了解您的体系结构，并（希望）花更多的时间完成真正的工作。
并且经过MS和世界各地开发人员的良好测试。@gbs:非常好。滚动您自己的用户身份验证框架就像滚动您自己的加密系统一样。《好钱》说你实际上并不比那些写世界上其他人都用的东西的人聪明。@gbs我确实想知道，在能够开发替代品的专业社区中，提供商的渗透有多大。我想这就是答案。