2

在我的 ASP.NET MVC3 应用程序中，我拥有用户、角色和实体。用户角色将有权访问实体。那么在将用户和角色存储在数据库中时，以下哪个是好方法？

  1. 将用户列表存储在实体表中

  2. 用户表中的实体 ID。

将来实体的数量可能会增加到 1000,10000，所以我也想考虑性能方面。

4

2 回答 2

1

我认为角色和实体之间的关系是多对多的。一个角色可以有零个或多个实体，一个实体可能属于零个或多个角色。所以创建第三个表来存储那些有 2 列的表，RoleId并且EntityID

样本数据看起来像

ROLE_ID        ENTITY_ID
-----------------------------------
1              144
1              146
2              194
4              14
4              194
于 2012-11-05T12:15:33.277 回答
0

根据应用程序所需的控制粒度，您可能需要考虑在 Windows Identity Foundation (WIF) 中使用的模型，该模型现在是 .NET Framework 4.5 的一部分。这是一个基于声明的体系结构，用于您所称的Entity的术语是Resource。与您的模型不同的是它们也有Operation的概念。一个资源可以有很多操作，一个典型的操作是读、写、执行之类的。这就是更精细的控制粒度的用武之地。

所以在这种情况下，一个特定资源的操作可以有很多角色，一个角色可以有很多操作，需要另一个表来映射这种多对多关系。使用 int 作为角色和操作中的主键作为对象 ID 有利于性能。 User可以有很多Roles并且Roles会有很多Users，因此您将再次需要另一个表来管理这种多对多关系。

所以问题 1 的答案是您不要将用户列表存储在实体表中。您有一个单独的User表，该表映射到Users-To-Roles表，该表映射到Roles，该表映射到Roles-To-Operations，该表映射到一个Operations表，该表映射到Resources表。如果您不需要操作的粒度，请消除该表并通过另一个表将您的角色映射到资源以处理这种多对多关系。

问题 2 的答案是否定的，用户表中不会有实体（资源）ID 。用户通过我上面描述的关系映射到资源。

使用此模型和基于声明的体系结构的全部范围的最佳方法是不使用AuthorizeAttribute将角色分配给您的方法，这在过去通常是这样做的。而是将资源和操作分配给您的方法，从而将您的安全策略与您的应用程序分离。对于这种方法的模型，请查看ClaimsPrincipalPermissionAttribute。您可以创建自己的使用此方法的自定义 AuthorizeAttribute。

于 2012-11-05T14:36:39.273 回答