ASP.NET 角色和配置文件：查询与自定义配置文件属性匹配的用户集合的最佳方法？
ASP.NET 2.0 成员资格、角色和配置文件是猫的喵叫。 角色 API 支持方便的方法，例如 GetAllUsersInRole("MyNewsletterSubscriber")，它将返回具有“MyNewsletterSubscriber”角色的人员的集合。
我想知道返回具有自定义 ASP.NET 配置文件属性的人员集合的最佳方法是什么。 例如，我可能会创建一个名为 IsNewsletter1SubscriptionUserSelectionTextOnly 的自定义配置文件属性和另一个名为 IsNewsletter1UserSelectionMobileOptimized 的自定义配置文件属性。
那么，我怎样才能最有效地查询类似于 GetAllUsersWithCustomProfileProperty("IsNewsletter1SubscriptionUserSelectionTextOnly", true); 的内容？
对于我设想的用途，围绕配置文件的 API 似乎尚未开发——我认为 Scott Guthrie 在 2006 年 Tech Ed 演讲中提到了一些即将开展的工作，但我不知道已经做了什么。
也可能是我试图不恰当地使用配置文件，最好将所有这些垃圾存储为直接角色。 不知道。 我喜欢使用角色或配置文件进行列表管理的想法，但我不知道管理它的最干净的方法。
想法、想法、答案？ 谢谢...
ASP.NET 2.0 membership, roles, and profiles is the cat's meow. The API for roles supports handy methods like
GetAllUsersInRole("MyNewsletterSubscriber"), which will return a collection of people in the "MyNewsletterSubscriber" role.
I am wondering what the best way to return a collection of people with custom ASP.NET Profile properties might be. So for example, I might create one custom profile property called IsNewsletter1SubscriptionUserSelectionTextOnly and another custom profile property called IsNewsletter1UserSelectionMobileOptimized.
How then, can I most efficiently query for something akin to GetAllUsersWithCustomProfileProperty("IsNewsletter1SubscriptionUserSelectionTextOnly", true);
For the use I'm envisioning, the API around Profiles seems underdeveloped -- I think Scott Guthrie mentioned some forthcoming work on it at his talk at Tech Ed 2006, but I don't know what's been done.
It may also be that I'm trying to use Profiles inappropriately, and it would be better to store all of this junk as straight roles. Don't know. I like the idea of using Roles or Profiles for list management, but I don't know the cleanest way to manage it.
Thoughts, idea, answers? Thanks...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，对配置文件进行查询（至少使用默认的 SQL 实现）是可怕的，因为您实际上是在二进制序列化字段上查询，因此每个查询都需要加载数据库中的每一行，反序列化所述二进制文件，然后检查答案。 因此，不要欺骗并使用 LINQ to Objects 之类的东西来完成此操作，您的 DBA 会开枪打死您。
无论如何，我的规则是，一旦您想查询个人资料，您最好实现一个可以正常方式查询的自定义提供程序。 通常这最终会成为领域模型的一部分。
Well, querying on profiles--at least with the default SQL implementation--is scary because you are really querying on a binary serialized field, so every query needs to load every row in the database, deserialize said binary and then check the answer. So don't cheat and do it with LINQ to Objects or something, your DBA will shoot you.
Anyhow, my rule is as soon as you want to query on profile, you had better implement a custom provider that is queryable in a normal fashion. Usually this ends up being part of the domain model.