c# - 大多数人使用 .NET 的 SqlMembershipProvider、SqlRoleProvider 和 SqlProfileProvider 吗？

Question

大多数人在开发具有成员资格功能的站点时是否使用 .NET 的 SqlMembershipProvider、SqlRoleProvider 和 SqlProfileProvider？

还是有很多人自己创建提供商，甚至完全创建自己的会员系统？

SQL 提供程序有哪些限制可以让您自行开发？

扩展 SQL 提供程序以提供附加功能是否容易？

score 6 · Accepted Answer

我们使用除 Profile Provider 之外的所有内容。Profile Provider 完全基于文本并进行全文搜索——随着用户群的扩大，这变得非常缓慢。我们发现它是一个更好的解决方案来“扮演我们自己的”会员 api 数据库的配置文件部分，该部分以会员身份的用户 ID 为关键字。

score 2 · Accepted Answer

MembershipProvider我已经使用派生类型推出了自己的类MembershipUser来包装自定义用户模式，因此配置文件样式的属性现在可以作为派生用户的一部分通过强制转换随处使用。

score 1 · Accepted Answer

我通常使用开箱即用的提供程序，我遇到的主要问题是跨用户查询个人资料属性。例如，查找具有名为 Car 的配置文件属性等于 true 的所有用户。这取决于它们在底层结构中的存储方式。

score 1 · Accepted Answer

我以前使用过 SqlMembership，它非常好，除非您需要自定义的东西。我记得需要像名字和姓氏信息这样的东西，我意识到没有字段。最后，我没有扩展，而是使用了提供者的 Comment 字段并在那里添加了名称信息。这可能是一种不好的做法/懒惰/黑客方式，但它在紧张的情况下对我有用..

score 0 · Accepted Answer

从理论上讲，它们听起来不错，但如果您在没有创建大量抽象包装器的情况下进行任何单元测试，则没有机会。

score 0 · Accepted Answer

如果您只需要基本的用户支持（角色、配置文件等），那么默认提供程序会很好用。

如果您需要更多自定义支持（默认提供程序 [如 Oracle] 不支持的数据库中的数据存储、已经存在的数据库上的提供程序、高度自定义的模式），那么您应该推出自己的提供程序。

至于我，我当前的站点只需要基本的角色支持（和最少的配置文件支持），所以我选择了默认提供程序。

score 0 · Accepted Answer

我已经使用了自定义类和内置类。当您需要访问不同的数据库或模式或需要额外信息时。

我抽象了这些层，以便它可以在逻辑层上工作，并有一个使用 data.common.dbprovider 位的 DAL 层，因此它是相当通用的。

7 回答 7