大多数人在开发具有会员资格功能的网站时是否使用.NET的SqlMembershipProvider，SqlRoleProvider和SqlProfileProvider？
或许很多人完全建立自己的提供者，甚至是自己的会员制度？
SQL提供程序的哪些限制会让您自己动手？
扩展SQL提供程序以提供其他功能是否容易？
供参考
Per Scott Gu's Blog，Microsoft provides the source code for the SqlMembershipProvider以便您可以自定义它，而不是从头开始。只是一个FYI。
答案 0 :(得分：6)
我们使用除Profile Provider之外的所有内容。 Profile Provider是完全基于文本的，可以进行全文查看 - 随着用户群变大，这变得非常慢。我们发现它是一个更好的解决方案，可以成为会员资格的成员api数据库的“角色我们自己的”个人资料部分。
答案 1 :(得分：2)
我使用派生的MembershipProvider类型滚动我自己的MembershipUser类来包装自定义用户架构，因此配置文件样式属性现在可以通过强制转换作为派生用户的一部分在任何地方使用。< / p>
答案 2 :(得分：1)
我通常使用开箱即用的提供程序，我遇到的主要问题是跨用户查询配置文件属性。例如，查找具有名为Car的配置文件属性的所有用户等于true。这取决于它们存储在底层结构中的方式。
答案 3 :(得分：1)
之前我使用过SqlMembership而且非常好，除非你需要定制的东西。我记得需要像firstname和lastname信息这样的东西，我意识到那里没有字段。最后，我没有使用扩展，而是使用了提供程序的Comment字段，并在那里添加了名称信息。这可能是一种糟糕的做法/懒惰/黑客方式，但它在紧张的情况下对我有用..
答案 4 :(得分：0)
从理论上讲，它们听起来不错，但如果你在没有创建大量抽象包装的情况下进行任何单元测试，那就没有机会了。
答案 5 :(得分：0)
如果您只需要基本的用户支持（角色，配置文件等），那么默认提供商将会很好用。
如果您需要更多自定义支持（默认提供程序[如Oracle]不支持的数据库中的数据存储，已存在的数据库上的提供程序，一个高度自定义的架构），那么您应该推送自己的提供程序。
至于我，我当前的网站只需要基本的角色支持（以及最小的个人资料支持），所以我选择了默认的提供商。
答案 6 :(得分：0)
我已经使用了两个自定义类并且内置了。当你需要访问不同的数据库或模式或者需要额外的信息时。
我抽象出了层，以便它可以在逻辑层上工作，并且有一个使用data.common.dbprovider位的DAL层，因此它是相当通用的。