权限设计方案.docx

权限管理设计
« 博客分类：
« 设计
设计模式数据结构
应用程序权限设计
我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设
基于角色的权限设计
这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设 计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色 对是否具有操作的权限进行控制；这里我们就不做详述
User
订
UserRole
Role
UiurlD
V»rID
RolelD
UserNanie：
RolelD
[
RoleN^fnig
基于操作的权限设计
这种模式下每一个操作都在数据库中有记录， 用户是否拥有该操作的权限也在数据库中
有记录，结构如下：
但是如果直接使用上面的设计，会导致数据库中的
以我们需要进一步设计提高效率，请看方案 3
基于角色和操作的权限设计
UserAction这张表数据量非常大，所
如上图所示，我们在添加了 Role,和RoleAction表，这样子就可以减少 UserAction中的
记录，并且使设计更灵活一点。
但是这种方案在用户需求的考验之下也可能显得不够灵活够用， 例如当用户要求临时给
某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色 是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工 权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。
2,3组合的权限设计，其结构如下：
UserAction
uswir
ActioitXD
HasPermi ssin
A-
V
CO.
Role
Tim
Act ion
Acti onNanie
UserRole
RoleAction
UserID
RolelD
J
ActicnID
我们可以看到在上图中添加了 UserAction表，使用此表来添加特殊用户的权限，改表中
有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的 优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过 UserRole
和UserAction两张表中的记录判断权限。
到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种 action所操作的对象
某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某
一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需 要设计更复杂的权限机制。
对于同一种实体（资源）用户可以对一部分记录有权限，而对于另外一些记录没
有权限的权限设计：
Channel
ID
Home
Bescripti on
User
I UserID
VstrKamt
UserActionChannel
UstrlD icti onlD ChiiknellB Hasf ermi esiil
UserActionContcn
UserID
rv
Acti onXD
CcntentID
HasPermissi on
Action
Acti orJD
Acti
KescurceTypi
Content
ID
N刘电
Description
对于这样的需求我们就需要对每一种不同的资源创建一张权限表，在上图中对 Con te nt
和Channel两种资源分别创建了 UserActionContent和UserActionChannel表用来定义用户 对某条记录是否有权限；这种设计是可以满足用户需求的但是不是很经济，
UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记 录所有的记录的权限信息，有时候可能只是一种规则，比如说对于根 Channel什么级别
的人有权限；这时候呢我们就可以定义些规则来判断用户权限，下面就是这种设计。
6.
涉及资源，权限和规则的权限设计
Channel
ID
Name
Description
ActionRule
ID
RuleType
Assembly
5
User
UserID
UserName
Action
实现业务系统中的用户权限管理••设计篇
B/S系统中的权限比C/