我目前正在构建一个ASP.NET MVC Web应用程序。我的网站安全性（目前）是在我扩展的System.Web.Security Membership模型的扩展上构建的：
这对于安全机制来说已经足够了 - 虽然它使很多事情变得复杂，我可能更简单地做了。但是，它已经完成，这是一个非常有用的学习经验。虽然稍后我仍然可以将其全部删除，并将其替换为更具体的网站模型 - 我希望将所有用户配置文件信息保存在一个专门为该网站编制索引和构建的表中。
现在我已经开始开发用户个人资料。我需要存储比基本用户登录系统更多的用户信息。我查看了ProfileProvider，看起来它是一个完全不同的蠕虫。我喜欢它足够灵活，我可以直接从web.config配置用户配置文件，而不必重建我的对象，ProfileProvider处理其余的。令我感到恐惧的是PITA导致我的数据库运行查询或报告。这个事实可能会让我对ProfileProvider的判断蒙上阴影。 ProfileProvider甚至是正确的模型吗？
我是否应该按照现有系统的定制或自定义构建我自己的系统的方式走同一条道路？
一方面，它对ProfileProvider的定制可能是一个有用的学习体验，但另一方面，我可以看到这迅速成为一个报告和查询的噩梦。但编码我自己将使查询/报告非常简单，但我不会学到更多。
如果有人有使用或定制ProfileProvider模型的经验（如果这确实是我应该使用的），可以指出我有用的阅读材料的方向或可以引导我在一个更有用的方向我我真的很感激。
提前致谢。
答案 0 :(得分：0)
我使用数据库中的表来实现安全性。基于表格的方法易于实现，易于理解，并且通过简单地将表格连接到要修剪的项目表来提供安全修整。报告很简单，基于表的安全性也可用于角色。
我刚刚发现ASP.NET MVC中现有的安全模型很麻烦，并没有做我需要它做的一些事情。特别是，很难在需要从数据库访问ID的文档记录等事物上应用属性，因为最终查看记录两次;一次在属性类中，一次在控制器方法的存储库中。
在所有其他条件相同的情况下，我宁愿维护一个安全系统而不是两个安全系统。所以我使用内置的安全性来验证用户，但之后我切换到基于表的安全性。
答案 1 :(得分：0)
我在一些书籍和许多博客中读到，要走的路是基于Microsoft提供的基类实现自己的MembershipProvider，RoleProvider和ProfileProvider，这就是我所做的。但最后，我最终将所有代码更改为我自己的基于自定义的安全架构，这为我提供了所需的所有灵活性。
问题在于那些提供商做出了许多可能无法适应您系统的假设。例如，MembershipProvider的create方法需要问题和答案作为参数（我不需要）或者如果你需要另一个属性，它开始变得很麻烦，代码和维护......让我们不谈论测试它......
就像你说的那样，学习体验总是很好，但为了满足我的需要而必须维护的代码量并不值得。
至于AuthorizeAttributte，我所做的是创建了适合我自己的安全架构的自己的过滤器。
我的建议？如果您的要求符合Microsoft认为的ProfileProvider应该是什么样子，那就去吧。如果没有，建立自己的。您可以复制他们执行的一些实践，但它可以让您随时随地进行更改。