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