【转】通用权限管理设计 之 功能权限设计

一，前言 

权限管理系统的应用者应该有三种不一样性质上的使用，

A,使用权限

B,分配权限

C,受权权限 

本文只从《使用权限》和《分配权限》这两种应用层面分析，暂时不考虑《受权权限》这种。

二，初步分析

用户和角色 

说到权限管理，首先应该想到，固然要设计一个用户表，一个权限表。这样就决定了一我的有什么样的权限。

作着作着就会发现这样设计太过繁琐，若是公司里面全部员工都有这样的权限呢，每个人都要配置？那是一件很痛苦的事情。所以再添加一个角色表，把某些人归为一类，而后再把权限分配给角色。角色属下的用户也就拥有了权限。

用户、角色之间的关系是一个用户能够对应多个角色，一个角色能够对应多个用户。多对多关系。

因此须要一个中间表，相信你们都很熟悉，天然不会有疑问。

应用场景 

有了用户和角色之后，就须要设计应用场景，好比一个应用程序有几大模块（系统模块、项目管理模块、销售模块），

相似这样的模块就是一种应用场景，常见的还有 菜单 、 操做 等等。

假设如今咱们设计好了，应用场景包括 模块、菜单、和操做，那么应该有如下六种关系

1. 一个用户能够对应多个模块，一个模块能够对应多个用户。多对多关系。
2. 一个用户能够对应多个菜单，一个菜单能够对应多个用户。多对多关系。
3. 一个用户能够对应多个操做，一个操做能够对应多个用户。多对多关系。
4. 一个角色能够对应多个模块，一个模块能够对应多个角色。多对多关系。 
5. 一个角色能够对应多个菜单，一个菜单能够对应多个角色。多对多关系。  
6. 一个角色能够对应多个操做，一个操做能够对应多个角色。多对多关系。

因而创建六张表来维护这六种关系。

这样设计看起来没什么问题。是的，若是没有加入新的关系的话，这样是已经能够知足大部分的需求了。但是若是就是若是，新的关系（需求）每每会加入到系统进来。这个时候就须要再创建一个新的表。系统的复杂度也随着增长。

能够看出，这样的设计有几个问题：

 

1. 数据表设计太复杂
2. 应对系统方案过于固定

三，把问题简单化

 

 不一样的应用场合，你可能会想出不一样的需求，提了一个新的需求之后，可能会发现原来的设计没方法实现了，因而还要添加一个新的表。这也是上面所提到的问题。 

 其实没必要想得那么复杂，权限能够简单描述为：

某某主体 在 某某领域 有 某某权限 

1，主体能够是用户，能够是角色，也能够是一个部门

2， 领域能够是一个模块，能够是一个页面，也能够是页面上的按钮

3， 权限能够是“可见”，能够是“只读”，也能够是“可用”(如按钮能够点击)

其实就是Who、What、How的问题

 

所以上面所提到的六张表其实能够设计一张表：

 

 

 

四，实例说明

 

下面用一个例子作设计说明。“用户、角色在页面上的是使用权限”

详细设计：

1，把菜单的配置放在数据库上，每个菜单对于一个惟一的编码MenuNo，每个“叶节点”的菜单项对于一个页面(url)。

2，把按钮的配置放在数据库上，并归属于一个菜单项上（其实就是挂在某一个页面上）。应该一个页面可能会有几个按钮组，好比说有两个列表，这两个列表都须要有“增长、修改、删除”。因此须要增长一个按钮分组的字段来区分。

3,把菜单权限分配给用户/角色，PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Menu",PrivilegeAccessValue为MenuNo,PrivilegeOperation为"enabled"

4,把按钮权限分配给用户/角色，PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Button",PrivilegeAccessValue为BtnID,PrivilegeOperation为"enabled"

5,若是须要禁止单个用户的权限，PrivilegeOperation 设置为"disabled"。

若是不清楚的能够看下图：

 

 数据库设计：

 

 

四，结语

说了这么多，其实我推荐的只是Privilege的表设计。这个表是who、what、how问题原型的设计。不只扩展性、灵活性都很好，并且将复杂的权限管理系统浓缩成一句话。

 而PrivilegeOperation不单单只是使用和禁止两种，包括分配权限、受权权限，均可以用这个字段定义。只是这无疑加大了应用程序的设计难度，可是对于表设计能够不作出任何的修改就能够完成，能够看出其灵活性。