.NET的SqlMembershipProvider、SqlRoleProvider和SqlProfileProvider是不是大多数人都用？大多数人在开发具有会员功能的站点时是否使用.NET的SqlMembershipProvider、SqlRoleProvider和SqlProfileProvider？也许许多人完全建立了自己的供应商，甚至是他们自己的会员系统？SQL提供程序的哪些限制你会逼迫自己？SQL提供程序是否可以轻松扩展以提供附加功能？供参考根据ScottGu的博客，Microsoft提供了SqlMembershipProvider的源代码，以便您可以自定义它而不是从头开始。仅供参考。我们使用除ProfileProvider之外的所有内容。配置文件提供程序完全基于文本并允许全文查看——随着用户群的扩大，这会变得非常慢。我们发现，成为会员api数据库的“我们自己的角色”个人资料部分是一个更好的解决方案，它是会员的用户ID。我使用派生的MembershipUser类型来滚动我自己的MembershipProvider类来包装自定义用户模式，因此配置文件样式属性现在作为派生用户的一部分通过转换在任何地方都可用。我通常使用开箱即用的提供程序，我遇到的主要问题是跨用户查询配置文件属性。例如，查找配置文件属性名为Car等于true的所有用户。这取决于它们在底层结构中的存储方式。我以前使用过SqlMembership，它非常好，除非您需要一些自定义的东西。我记得我需要名字和姓氏之类的信息，但我意识到那里没有字段。最后，我没有使用扩展名，而是使用了提供商的Comment字段并在其中添加了名称信息。这可能是一种不好的做法/懒惰/hack方式，但它在紧张的情况下对我有用。理论上它们听起来不错，但如果你在没有创建大量抽象包装器的情况下进行任何单元测试，那么就没有机会.如果您只需要基本的用户支持（角色、配置文件等），那么默认提供程序就很棒。如果您需要更多自定义支持（默认提供程序[如Oracle]不支持的数据库中的数据存储、现有数据库上的提供程序、高度自定义的模式），那么您应该推送自己的提供程序。至于我，我当前的站点只需要基本角色支持（和最少的配置文件支持），所以我选择了默认提供程序。我使用了自定义类和内置类。当您需要访问不同的数据库或模式或需要其他信息时。我将这些层抽象化，以便它在逻辑层上工作，并有一个使用data.common.dbprovider位的DAL层，因此它非常通用。以上是C#学习教程：.NET的SqlMembershipProvider、SqlRoleProvider和SqlProfileProvider是不是大多数人都用？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
