问实体框架:权限、用户等的关系模型帮助

EN

考虑到你的客户和供应商数量非常少(总共20家)，你不需要一个非常复杂的系统。

我在类似的情况下所做的就是设置了一个具有如下结构的权限表：

• UserId (用户id )
• RoleId (链接到角色表的id，带有诸如“编辑客户”、“删除供应商”、查看客户等内容)
• ObjectId (这将是标识您要保护的任何对象的id，因此供应商id或客户id。)

角色表将包含：

• Id (唯一id与权限表中的RoleId相关)
• name (角色的唯一名称，即‘编辑客户’)

然后将每个用户实体链接到一个权限表，每个用户具有多个权限。当用户登录时，我通常会选择将他们的所有权限加载到内存列表中，这样用户就会有一个权限列表。权限列表将只包含ObjectId、RoleName和/或RoleId (我倾向于使用rolename以使代码更易于阅读，如下面的示例所示)。

protected bool HasPermission(long ObjectId, string RoleName)
{

//Users in the Administrator role have access to everything in the system.
if (this.IsAdministrator) {
    HasPermission = true;
    return;
}

foreach (Permission P in Permissions) {
    if (P.ObjectID == ObjectID & P.RoleName == Role) {
        HasPermission = true;
        return;
    }
}
return false;

}

然后，如果我想知道用户是否有权限访问某事，我会这样做：

if (myUser.HasPermission(CustomerId, "Edit Customer") {
  //allow the user to edit the customer
else
  //allow the user to only view the customer (for example)

或

    if (myUser.HasPermission(SupplierId, "Print Supplier") {
  //allow the user to print the record
else
  //give user a warning

关键是，每个“角色”需要是唯一的，你不能有一个通用的“编辑”角色，因为如果你有一个拥有相同id的客户和供应商，而你想看看用户是否有“编辑”的权限，你可能会得到错误的结果。因此有一个名为“编辑客户”的角色和另一个名为“编辑供应商”的角色。

这种解决方案不能很好地扩展imo，但对于只有几十条需要保护的记录的数据库来说，它工作得很好，而且易于实现和维护。它也不是以真正的关系方式设置的，即权限表中的ObjectId既不与供应商表也不与客户表相关。

(此外，在这种情况下，我的用户对象知道它是否是管理员，管理员不需要设置权限，可以访问所有内容，因此不需要搜索权限-节省了几纳秒的时间)