基于角色的权限设计(二)
第一部分请參看：http://blog.csdn.net/snomyc520/article/details/38677861
针对这种需求，版本号一就无能为力了（当然你也能够添加几个功能：比方分类A的新闻起草和分类B的新闻起草，再把这个功能加入到对应的角色里面去，可是这个应该不是我们要得解决方式吧，只是版本号二也是基于这个思想来解决的）。
事实上比新闻更好的样例是论坛板块的版主。
以下是版本号二的解决方式：
在版本号二的功能表中增加了一个ResourceType这个字段，这个字段用来表示对某个资源的分类（比方新闻），我们相同来模拟一下（新闻分类A的ResourceType为：NTA，分类B为：NTB）：
功能表：
然后在角色表加入相应的角色，在角色功能表中加入相应的功能。
获取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语句就不是如今这么简单了）。在我如今的应用里面没有实现角色的继承（尽管角色的编码体现出了角色的父子关系）。