在我的 Web 应用程序中对用户配置文件采取的最佳方法是什么？
我目前正在构建一个 ASP.NET MVC Web 应用程序。我的站点安全性（当前）构建在 System.Web.Security 会员模型的扩展之上，我在其中扩展了：
- AuthorizeAttribute
- MembershipProvider
- RoleProvider
这对于安全机制来说已经足够了 - 尽管它使我可能做的很多事情变得复杂更简单。然而，它已经完成了，这是一次非常有用的学习经历。尽管稍后，我仍可能将其全部删除并用更特定于该站点的模型替换它 - 我希望将所有用户配置文件信息保留在一个专门为该站点建立索引和构建的表中。
现在我开始开发用户个人资料。我需要存储比基本用户登录系统更多的用户信息。我检查了 ProfileProvider，它似乎是一个完全不同的蠕虫罐头。我喜欢它足够灵活，我可以直接从 web.config 配置用户配置文件，而无需重建我的对象，ProfileProvider 会处理其余的事情。但让我感到恐惧的是，这会导致 PITA 在我的数据库上运行查询或报告。这一事实可能会影响我对 ProfileProvider 的判断。 ProfileProvider 是否是用于此目的的正确模型？
我应该走与定制现有系统相同的道路还是定制构建自己的系统？
一方面，ProfileProvider 的定制可能是一种有用的学习体验，但另一方面，我可以看到这很快就会成为报告和查询的噩梦。但是编写我自己的代码将使查询/报告变得非常简单，但我不会学到更少的东西。
如果有人有任何使用或定制 ProfileProvider 模型的经验（如果这确实是我应该使用的），并且可以为我指明有用的阅读材料的方向，或者可以引导我走向更有用的方向，我将非常感激它。
提前致谢。
I'm currently building an ASP.NET MVC web application. My site security is (currently) built atop an extension of the System.Web.Security Membership model where I've extended:
- AuthorizeAttribute
- MembershipProvider
- RoleProvider
This has sufficed for the security mechanism - although it has complicated a lot of things I could probably have done more simply. However, it's done and it was a very useful learning experience. Although at a later point, I may still rip it all out and replace it with a model that is more specific to the site - I'd like to keep all my user profile information in a single table indexed and built specifically for the site.
Now I've moved onto development of the user personal profiles. I need to store a lot more user information than for the basic user log-in system. I've checked out the ProfileProvider which seems like it's a whole different can of worms. I like that it's flexible enough that I can configure user profiles right from the web.config without having to rebuild my objects and the ProfileProvider handles the rest. What horrifies me though is the PITA this causes to run queries or reporting on my database. This fact is probably clouding my judgment against the ProfileProvider. Is the ProfileProvider even the right model to be using for this?
Should I go down the same road I did with the customization of the existing system or custom build my own system?
On one side, it going down the customization of the ProfileProvider could be a useful learning experience but on the other hand, I can see this rapidly becoming a reporting and querying nightmare. But coding my own is going to make querying/reporting very simple but I'm not going to learn much less.
If anyone has any experience with use of or customization of the ProfileProvider model (if that indeed is what I should be using) and can either point me in the direction of useful reading material or can steer me in a more useful direction I would really appreciate it.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我在一些书籍和许多博客中读到，可行的方法是基于 Microsoft 提供的基类实现自己的 MembershipProvider、RoleProvider 和 ProfileProvider，这就是我所做的。但最后，我最终将所有代码更改为我自己的基于自定义的安全模式，这为我提供了所需的所有灵活性。
问题是这些提供商做出了很多可能不适合您的系统的假设。例如，MembershipProvider 的 create 方法需要问题和答案作为参数（我不需要），或者如果您需要另一个属性，那么编码和维护就开始变得麻烦。我们不谈论测试它...
就像你说的，学习体验总是好的，但是为了满足我的需求而我必须维护的代码量是不值得的。
至于 AuthorizeAttributte，我所做的是创建适合我自己的安全架构的自己的过滤器。
我的建议？如果您的要求符合 Microsoft 认为 ProfileProvider 应有的样子，那就去做吧。如果没有，请构建自己的。您可以复制他们执行的一些做法，但它使您可以自由地在任何需要的地方进行更改。
I read in some books and many blogs that the way to go was to implement your own MembershipProvider, RoleProvider and ProfileProvider based on the base class that Microsoft provides, and that's what I did. But at the end, I ended up changing all that code to my own custom-based security schema, which gives me all the flexibility I require.
The problem is that those providers make a lot of assumptions that might not accommodate to your system. For example, the create method of the MembershipProvider requires question and answer as parameters (which I didn't require) or if you need another attribute, it starts becoming cumbersome to code and maintain.. And let's not talk about testing it...
Like you said, the learning experience is always good, but the amount of code that I had to maintain to make it fit my needs was not worth it.
As for the AuthorizeAttributte, what I did was I created my own filters that fit my own security schema.
My advise? If your requirements fit what Microsoft thinks a ProfileProvider should look like, go for it. If not, build your own. You can copy some of the practices they execute, but it gives you the freedom to change wherever you have to.
我使用数据库中的表来实现安全性。基于表格的方法实施简单、易于理解，并且通过简单地将表格连接到要修剪的项目表来提供安全修剪。报告非常简单，基于表的安全性也可用于角色。
我只是发现 ASP.NET MVC 中现有的安全模型很麻烦，而且它没有做一些我需要它做的事情。特别是，很难将属性应用于需要从数据库访问 ID 的文档记录等内容，因为您最终会查找该记录两次；一次在属性类中，一次在控制器方法的存储库中。
在其他条件相同的情况下，我宁愿维护一个安全系统而不是两个。因此，我使用内置安全性来验证用户身份，但之后我切换到基于表的安全性。
I use tables in the database to implement security. A table-based approach is simple to implement, easy to understand, and provides for security trimming by simply joining the table to the table of items to be trimmed. Reporting is straightforward, and table-based security can be used for roles as well.
I just found the existing security model in ASP.NET MVC to be cumbersome, and it didn't do some of the things I needed it to do. In particular, it's difficult to apply attributes on things like document records that require access to an ID from the database, because you wind up looking the record up twice; once in the attribute class, and once in the repository for the controller method.
All other things being equal, I would rather maintain one security system than two. So I use the built-in security to authenticate the users, but after that I switch to table-based security.