我编写了一些复杂的MVC应用程序，它们都是基于角色的，并使用.NET Membership。在我的第一个项目中，我使用了与此类似的结构角色：
我很快发现它的可扩展性不高，例如客户会说“我希望特定用户x拥有所有管理员权限，但不删除”。然后，我必须在该控制器中为该用户设置一个黑客。
因此，我的第二个实现导致了这个角色结构：
这种方法根据他们是否可以全局编辑特定项目或者只是他们自己的等等来导致字面上数十个角色。它还会导致更多的控制器操作和更多的代码 - 尽管可能这就是复杂应用中的情况！
我的问题是，我是否以正确的方式接近这一点，是否有任何良好的在线资源以“正确”的方式来处理具有大量角色的复杂应用程序。我这样做了吗？
答案 0 :(得分：4)
确实这是一个非常有趣的主题，我发现自己正在努力解决与你相同的问题。
我阅读了Derick Baileys关于“不做基于角色的授权检查;基于活动的检查”的有趣博客：http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
但是我没有时间自己精力充沛。
答案 1 :(得分：1)
从这个问题开始的一年，我以不同的方式处理项目。我现在坚持经典的角色：
但是动作方法本身会返回如下数据：
var order = or.MyVisibleOrders().FirstOrDefault(x => x.Id == Id);
然后由存储库中的角色处理可查看和不可查看的逻辑。首先，数据库基本上不会被查询受限制的项目。
基本的东西，但觉得我应该跟进自己。