SqlMembershipProvider vs自定义解决方案

Question

我在一个小团队的开发人员的工作，并没有达成一致的核心任务，其中一个是成员资格提供商的最佳方法的共识。现在我不能确定这是否涉及到缺乏替代思维方式或足够规模的项目以保证进行重大调查。

我一直是一个.NET网络开发人员多年（以及之前的PHP和ASP经典），并且通常在开发应用程序时，我害怕使用内置的.net SqlMembershipProvider，这主要是因为它经常显得过分其次，因为我只能想象这样一个复杂的数据模型可能会有性能问题。

通常我使用一个自定义成员资格和角色提供程序在相当简单的user -> user roles <- roles类型模式上运行。根据相关应用程序的需求，我维护标准的成员资格提供程序功能，例如帐户恢复，配置文件详细信息，失败的登录帐户锁定，秘密问题等，例如AD安全应用程序具有少量附加功能，面向公众的应用程序通常具有商场。这也意味着任何需要存储过程的任务都需要咀嚼用户数据，这些任务很容易编写和执行。直接的SQL命令，良好的索引和简单的数据模型导致高性能，可伸缩的解决方案，这应该需要改变我完全可以控制需要改变，我认为这是非常宝贵的。

根据你的经验，你会说这是一个过时的方法？内置提供程序是否存在可扩展性问题？你通常采取什么方法以及在什么情况下？

感谢

Answer 1

除非你明确地确定了不合理的理由，否则我建议你从SQLMembershipProvider开始，并根据需要对其进行调整。

我们发现内置提供程序给了我们所有的基本知识，而我们几乎没有任何工作。要建立一个良好的安全结构有很多元素，很容易忘记其中的一个，或者只是为了让自己变得懒惰而不实现一个“正确”的方式。让我们想起通过电子邮件重置密码和密码的事情。

当然，SQLMembershipProvider并不是什么灵丹妙药。我们遇到了一些情况，需要采取更复杂的身份验证措施。但是我们能够通过扩展SQLMembershipProvider来解决这些问题，而不是取而代之。有关更多详情，请参阅我的回答What is a good way to extend .Net Membership to track user logins。

我们没有注意到来自SQLMembershipProvider的任何重大性能问题，所以我认为玩性能卡是没有根据的。毕竟，用户通常花费多少时间登录系统？如果你所有的网页加载速度都很快，那么根据你可能会错误地改进性能的想法来编写你自己的代码是没有道理的。这是我们一直在阅读的可怕的“过早优化”。

Roles框架对我们的需求来说太简单了，所以我们根本不使用它。但它也没有成功。如Hogan指出的那样，您更有可能找到已经熟悉内置提供者工作方式的开发人员，这意味着他们将花更少的时间来设法确定您的架构和（希望）有更多时间完成实际工作。

Answer 2

使用内置提供商应该更容易维护，并找到熟悉的API（招聘程序员的时候）资源。