基于角色的权限设计（二）

针对这样的需求，版本一就无能为力了（当然你也可以增加几个功能：比如分类A的新闻起草和分类B的新闻起草，再把这个功能添加到相应的角色里面去，但是这个应该不是我们要得解决方案吧，不过版本二也是基于这个思想来解决的）。

其实比新闻更好的例子是论坛板块的版主。

下面是版本二的解决方案：

在版本二的功能表中加入了一个ResourceType这个字段，这个字段用来表示对某个资源的分类（比如新闻），我们同样来模拟一下（新闻分类A的ResourceType为：NTA，分类B为：NTB）：

功能表：

FunctionID	ResourceType	FunctionName
F1	NTA	起草新闻：分类A
F2	NTA	编辑新闻：分类A
F3	NTA	审核新闻：分类A
F4	NTA	删除新闻：分类A
F1	NTB	起草新闻：分类B
F2	NTB	编辑新闻：分类B
F3	NTB	审核新闻：分类B
F4	NTB	删除新闻：分类B

然后在角色表添加相应的角色，在角色功能表中添加对应的功能。

获取Functions的语句也相应地做变化：

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

权限的判断也就变成：

Functions.Contain(‘F1,NTA’);

在新添加一个分类的时候，同时也在功能表中增加相应的记录（当然不是在数据库里面直接添加，由和功能相关的函数来添加）。

使用这种解决方案可以简单地对有分类的应用（比如论坛系统）的每个分类实行不同的控制（比如VIP板块，就只能拥有VIP角色的用户才能浏览、发表等，而其他板块只要是注册用户就可以使用了）。

在实际应用中FunctionID并不是随便的一个字符串，而是进行了编码，其编码中包含了模块ID以及能够体现出父子关系，举个例子来说：对于论坛系统，我们给它一个模块ID为”30”，论坛的功能我们先分成2类，一类是管理类（比如删除帖子），一类是使用类（比如发帖、回帖、浏览帖子等），给管理类一个编码：01，使用类一个编码：02，我们就对FunctionID进行如下的编码：

300101：删除帖子

300201：发帖

300202：回帖

300203：浏览帖子

对于资源（比如某个板块1，板块的ID为：01），我们可以组合出如下的Functions（当然这个组合你也可以不用逗号分隔，用其他的组合方式也可以，不过不要产生歧义）：

300101,01：板块1删除帖子的功能

300201,01：板块1发帖的功能

……

    对于RoleID也是采用的编码方式，也能体现角色的父子关系，也可以实现角色功能的继承等（当然获取角色功能列表的SQL语句就不是现在这么简单了）。在我现在的应用里面没有实现角色的继承（虽然角色的编码体现出了角色的父子关系）。