大多数人都使用 .NET 的 SqlMembershipProvider、SqlRoleProvider 和 SqlProfileProvider 吗？
大多数人在开发具有成员资格功能的站点时是否使用.NET 的 SqlMembershipProvider、SqlRoleProvider 和 SqlProfileProvider？
还是很多人都创建了自己的提供商，甚至完全是自己的会员系统？
SQL 提供程序有哪些限制会让您自行推出？
扩展 SQL 提供程序以提供附加功能是否容易？
供参考
Per Scott Gu 的博客，Microsoft 提供了 SqlMembershipProvider 的源代码您可以自定义它，而不是从头开始。 仅供参考。
Do most people use .NET's SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider when developing a site with membership capabilities?
Or do many people make their own providers, or even their own membership systems entirely?
What are the limitations of the SQL providers that would make you roll your own?
Is it easy to extend the SQL providers to provide additional functionality?
For Reference
Per Scott Gu's Blog, Microsoft provides the source code for the SqlMembershipProvider so that you can customize it, instead of starting from scratch. Just an FYI.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我们使用除配置文件提供程序之外的所有内容。 配置文件提供程序完全基于文本并进行全文搜索 - 随着用户群变大，这会变得非常慢。 我们发现这是一个更好的解决方案，可以“扮演我们自己的角色”会员 API 数据库的配置文件部分，该数据库以会员中的用户 ID 为键。
We use everything except the Profile Provider. The Profile Provider is completly text based and does full text seearches - this becomes exceedingly slow as you user base gets larger. We have found it a much better solution to "role our own" profile section of the membership api database that is keyed to the userid in membership.
我已经使用派生的
MembershipUser类型推出了自己的MembershipProvider类来包装自定义用户架构，因此配置文件样式属性现在可以作为派生用户的一部分通过投掷。I've rolled my own
MembershipProviderclasses using derivedMembershipUsertypes to wrap the custom user schema, so profile-style properties are now available everywhere as part of the derived user via a cast.我通常使用开箱即用的提供程序，我遇到的主要问题是跨用户的个人资料属性查询。 例如，查找具有名为 Car 的配置文件属性等于 true 的所有用户。 这取决于它们在底层结构中的存储方式。
I normally use the providers that come out of the box, the main problem I have is querying across profile attributes across users. For example finding all users that have a profile attribute called Car that equals true. This is down to the way they are stored in the underlying structure.
我以前使用过 SqlMembership，它非常好，除非您需要自定义的东西。 我记得需要诸如名字和姓氏信息之类的信息，但我意识到没有相应的字段。 最后，我没有扩展，而是使用了提供者的 Comment 字段，并向其中添加了名称信息。 这可能是一种不好的做法/懒惰/黑客方式，但它在紧张的情况下对我有用。
I've used SqlMembership before and it's quite nice, unless you need something custom. I remember needing something like firstname and lastname info and I realised there're no fields for that. In the end instead of extending I've used Comment field of the provider and added name info to there. This is probably a bad practice/lazy/hack way but it worked for me in a tight situation..
从理论上讲，它们听起来不错，但如果您在不创建大量抽象包装器的情况下进行任何单元测试，那么它们就没有机会。
In theory they sound nice, but not a chance if you do any unit testing without creating lots of abstract wrappers.
如果您只需要基本的用户支持（角色、配置文件等），那么默认提供程序将非常有用。
如果您需要更多自定义支持（默认提供程序 [如 Oracle] 不支持的数据库中的数据存储、现有数据库上的提供程序、高度自定义的模式），那么您应该推出自己的提供程序。
对于我来说，我当前的网站只需要基本的角色支持（和最少的配置文件支持），所以我使用了默认的提供程序。
If you only need the basic user support (roles, profiles, etc.) then the default providers will work great.
If you need more customized support (data storage in a database not supported by the default providers [like Oracle], provider on a database that already exists, a heavily customized schema) then you should roll your own providers.
As for me, my current site only needed basic Roles support (and minimal Profiles support), so I went with the default providers.
我使用了自定义类和内置类。当您需要访问不同的数据库或架构或需要额外信息时。
我抽象了这些层，以便它可以在逻辑层上工作，并有一个使用 data.common.dbprovider 位的 DAL 层，因此它相当通用。
I have used both the custom classes and built in. When you need to get to a different database or schema or need to have extra info.
I abstracted out the layers so that it would work on the logic layer and have a DAL layer that used the data.common.dbprovider bit so it was reasonably generic.