程序设计中的权限设计一

在任何系统中，权限设计是最基础的东西，本文给出一个基于角色的权限设计的循序渐进的设计方案。

　　在权限系统中，功能（权限）是最小的单位，比如起草新闻、编辑新闻、审核新闻、删除新闻等，而角色是一类功能的集合，比如新闻编辑这个角色，他可能有起草新闻、编辑新闻等功能集合，而责任编辑他可能就有更多的权限，比如除了新闻编辑的功能，还有审核新闻、删除新闻等功能，给张三赋予新闻编辑的角色（其实我更愿意说把张三加入到新闻编辑这个角色中去），张三就可以起草新闻、编辑新闻了，给李四赋予责任编辑的角色，李四就可以起草新闻、编辑新闻、审核新闻、删除新闻了。

　　我们来看看版本一的解决方案：


 

　　我们来模拟一下上面的数据：

　　用户信息表：

UserID	UserName
U1	张三
U2	李四

　　角色表：

RoleID	RoleName
R1	新闻编辑
R2	责任编辑

　　角色用户表：

RoleID	UserID
R1	U1
R2	U2

　　功能表：

FunctionID	FunctionName
F1	起草新闻
F2	编辑新闻
F3	审核新闻
F4	删除新闻

　　角色功能表：

RoleID	FunctionID
R1	F1
R1	F2
R2	F1
R2	F2
R2	F3
R2	F4

　　我们来看看如何判断一个用户具有某个功能权限：

　　首先在用户张三登录的时候，获取张三的全部功能列表：

Select FunctionID From 角色功能表 Where RoleID In (Select RoleID From 用户角色表 Where UserID=’U1’)

　　这样就可以得到张三的全部功能列表Functions，在起草新闻的页面我们就可以做如下判断：

Functions.Contain(‘F1’);//当然你可以把这个’F1’定义成一个常量：NewsFunction.Draft

　　如果为true就说明张三有起草新闻的权限。

　　当然对于web应用，您可以把Functions 用session保存起来，以避免每打开一个页面都去数据库中获取。

　　似乎看起来是一个不错的解决方案。

　　还是新闻系统，最初新闻系统没有分类，但是随着新闻的增加，没有分类的新闻看起来总是乱的，于是张三和李四给新闻添加了分类A、分类B，还是由张三负责起草，李四负责审核，以后又添加了更多的分类，并且也增加了人手，这个时候就有新的要求出来了：希望张三只负责分类A的起草，分类B的起草交给其他人做，李四呢也只负责分类A的审核（就相当于是一个栏目的责任编辑）。