SqlMembershipProvider 与自定义解决方案
我在一个小型开发团队中工作，对于完成许多核心任务（其中之一是会员提供者）的最佳方法没有达成共识。现在我不能确定这是否与缺乏对替代思维方式的接触或缺乏足够规模的项目以保证进行重大调查有关。
我已经成为 .net net 开发人员很多年了（在 php 和 asp 经典之前），通常在开发应用程序时我会回避使用内置的 .net SqlMembershipProvider 主要是因为它经常对于我的需求来说似乎过于复杂，其次是因为我只能想象如此复杂的数据模型可能会影响性能。
通常，我使用在相当简单的用户 -> 上运行的自定义成员资格和角色提供程序。用户角色 <- 角色 类型架构。我维护标准的会员提供商功能，例如帐户恢复、个人资料详细信息、登录失败帐户锁定、秘密问题等，具体取决于相关应用程序的需求，例如 AD 安全应用程序几乎没有附加功能，面向公众的应用程序通常具有商场。这也意味着如果出现任何需要存储过程来仔细研究用户数据的任务，它们很容易编写并且执行得很好。直接的 SQL 命令、良好的索引和简单的数据模型产生了高性能、可扩展的解决方案，该解决方案应该需要更改我可以完全控制根据需要进行更改，我认为这是无价的。
根据您的经验，您认为这是一种过时的方法吗？您是否曾经遇到过内置提供程序的可扩展性问题？您通常在什么场景下采取什么方法？
谢谢
I work in a small team of developers and there is no consensus on the best approach to do a number of core tasks, one being membership providers. Now I cannot be sure if this relates to lack of exposure to alternative ways of thinking or projects of sufficient scale to warrant significant investigation.
I’ve been a .net net developer for a number of years (and before that php and asp classic) and typically when developing applications I shy away from using the built in .net SqlMembershipProvider primarily because it often seems significantly over complicated for my needs, and secondarily because I can only imagine such a complex data model will likely have a performance hit.
Typically I use a custom membership and roles provider operating on a fairly simple user -> user roles <- roles type schema. I maintain the standard membership provider features such as account recovery, profile details, failed login account locking, secret questions, etc depending on the needs of the associated application such as an AD secured application has few additional features, a public facing application will usually have them all. It also means should any tasks that come up which require stored procs to chew through user data they’re easy to write and perform very well. Straight SQL commands, good indexing and a simple data model resulting in a high performance, scalable solution which should needs change I have full control to change as necessary which I considering invaluable.
Based on your experiences would you say this is an outdated approach? Have you ever had any scalability problems with the built in provider? What approach do you generally take and in what scenarios?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非您明确指出了不这样做的令人信服的理由，否则我建议您从 SQLMembershipProvider 开始，并根据需要进行调整。
我们发现内置提供程序为我们提供了所有基础知识，而我们几乎不需要做任何工作。开发一个良好的安全结构有很多要素，很容易忘记其中一个，或者只是因为懒惰而在自己推出自己的安全结构时没有以“正确”的方式实现其中一个。我会想到诸如加盐密码和通过电子邮件重置密码之类的事情。
当然，SQLMembershipProvider 并不是灵丹妙药。我们遇到过一些需要对身份验证进行更复杂的操作的情况。但我们只需扩展 SQLMembershipProvider（而不是替换它）即可解决这些问题。请参阅我的答案 扩展 .Net 会员资格以跟踪用户登录的好方法是什么了解更多详细信息。
我们没有注意到 SQLMembershipProvider 引起的任何重大性能问题，因此我认为打性能牌是没有根据的。毕竟，您的用户通常花费多少时间登录您的系统？如果您的所有页面加载速度都很快，那么就没有真正的理由在（可能是错误的）您将提高性能的想法下编写所有自己的代码。这就是我们不断读到的可怕的“过早优化”。
角色框架对于我们的需求来说太简单了，所以我们根本不使用它。但它也没有妨碍。
而且，正如 Hogan 指出的那样，您更有可能找到已经熟悉内置提供程序工作方式的开发人员，这意味着他们将花费更少的时间来尝试弄清楚您的架构，并且（希望）有更多的时间完成真正的工作。
Unless you've specifically identified compelling reasons not to, I'd suggest you start with the SQLMembershipProvider, and tweak it as necessary.
We've found that the built-in provider gave us all the basics with practically no work on our part. There are so many elements to developing a good security structure, and it's easy to forget one of them, or simply to get lazy and not implement one the "right" way when you're rolling your own. Things like salted passwords and password resets via email come to mind.
Of course, the SQLMembershipProvider is no magic bullet. We've had a few circumstances where we needed to do something more complicated with authentication. But we were able to resolve these just by extending the SQLMembershipProvider, rather than replacing it. See my answer at What is a good way to extend .Net Membership to track user logins for more details.
We have not noticed any significant performance issues stemming from the SQLMembershipProvider, so I think playing the performance card is unwarranted. After all, how much time do your users typically spend logging in to your system? If all your pages load quickly, there's no real justification for writing all your own code under the (possibly mistaken) idea that you'll be improving performance. It's that dreaded "premature optimization" we keep reading about.
The Roles framework was far too simplistic for our needs, so we don't use it at all. But it hasn't gotten in the way, either.
And, as Hogan points out, you're far more likely to find developers that are already familiar with the way the built-in provider works, which means they'll spend less time trying to figure out your architecture and (hopefully) more time getting real work done.
使用内置提供程序应该更容易维护并更容易找到熟悉 API 的资源（在雇用程序员时）。
Using built in providers should be easier to maintain and to find resources familiar with the api (when hiring programmers).