SqlMembershipProvider的VS定制的解决方案 [英] SqlMembershipProvider vs a custom solutions

问题描述

我工作在一个小团队的开发人员并没有在最好的办法没有达成一致意见做了一些核心任务，其中之一是会员供应商。现在，我不能肯定这是否涉及到曝光不足的思维替代方法或有足够规模的项目，以保证显著调查。

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.

我是一个.NET .NET开发了数年（和PHP和ASP经典的前），通常开发应用程序时，我回避使用内置的.NET 的SqlMembershipProvider 主要是因为它似乎常常显著过复杂，我的需要，其次是因为我能想象这样一个复杂的数据模型，将可能有一个性能命中。

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.

通常情况下我用一个相当简单的用户自定义成员资格和角色提供者操作 - ＆GT;用户角色＆LT; - 角色键入模式。我保持标准成员资格提供的功能，如帐户恢复，轮廓细节，失败的登录帐户锁定，秘密问题，等这取决于相关应用的需求，如AD保护的应用程序有一些额外的功能，一个面向公众的应用程序通常会商场。这也意味着应该是拿出其中需要存储的特效任何任务咀嚼通过它们很容易编写和执行得非常好用户数据。直接的SQL命令，良好的索引和导致高性能的一个简单的数据模型，可扩展的解决方案，其中应需求的变化我可以完全控制所必需的改变​​，我考虑无价的。

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?

感谢

推荐答案

除非你具体确定令人信服的理由不来，我建议你先从SqlMembershipProvider的，并在必要时对其进行调整。

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.

，该SqlMembershipProvider的是没有灵丹妙药。我们已经有一些情况下，我们需要做一些更复杂的身份验证。但是，我们能够仅仅通过延长SqlMembershipProvider的，而不是取代它来解决这些。请参阅我的答案在<一个href="http://stackoverflow.com/questions/4973820/what-is-a-good-way-to-extend-net-membership-to-track-user-logins/4973884#4973884">What是一个很好的方式来扩展的.Net成员来跟踪用户登录的更多细节。

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.

我们有没有注意到从SqlMembershipProvider的所产生的任何显著的性能问题，所以我觉得打性能牌是没有道理的。毕竟，有多少时间做你的用户通常会花登录到你的系统？如果您的所有网页快速加载，有没有真正的理由下（可能是错误的）想法，你会提高性能编写自己所有的code。就这么可怕的premature优化，我们不断念叨。

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.

这篇关于SqlMembershipProvider的VS定制的解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！