SqlMembershipProvider 与自定义解决方案

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 的资源（在招聘程序员时）。