框图

上图中，Role和被设置Permission的Resource都是可以有任意层级继承关系的。

举例

举一个网站的例子来说：

如果，User表示网站用户；Role表示角色；Resource表示所有可访问的URL；Permission是对每一个URL的某一个权限（如：查看，修改等）。

Role可以有任意层级继承关系，如：用户角色可以分为Normal User和Admin User，Admin User下又可以分为Super Admin、Content Admin、Support Admin等。

URL这种Resource也可以有任意层级继承关系的，如：对http://abc.com/A/A1/A11/A111.aspx这样一个链接，可以认为http://abc.com/A1是一个URL Resource，http://abc.com/A/A1/A11是他的一个子Resource，http://abc.com/A/A1/A11/A111.aspx又是http://abc.com/A/A1/A11的一个子Resource。

对某一个Role来说，他对某一个Resource – R1的具体的Permissions，等于关联到这个Role的Resource - R1及其所有父级Resource的Permissions的并集。

对于某一个User来说，他对某一个Resource的Permissions，等于他所属的所有Roles的Permissions的并集。

问题

各元素之间的关系容易理解，关键的难点在于，因为Role和Resource都可以是有无限层级继承关系的，如何保证权限信息验证具有较高的性能呢？当继承关系较复杂时，递归检测的性能无疑是不可接受的。

数据库表

User（ID，Name）

Role（ID，Name，ParentID，LeftIndex，RightIndex）

UsersInRoles（UserID，RoleID）

Resource（ID，Name，ParentID，LeftIndex，RightIndex）

PermissionsOfRole（PermissionsValue，ResourceID，RoleID）

这里简单起见，对于Permissions，使用一个二进制位表示一个具体的Permission。我们需要事先定义一个PermissionsValue的每一个二进制位表示的Permission。例如：如果PermissionsValue的二进制值为10101010，表示从低位到高位第2、4、6、8位所代表的权限的并集。

使用二进制位表示一个具体的Permission的好处是，处理Permissions的并操作可以转换为二进制的OR；缺点是，具体的Permission想不能特别多，因为多一个就意味着PermissionsValue的最大值大一个2的次方。8位二进制的最大值是2的8次方，这不算很大，但是，1000位二进制的最大值是2的1000次方，这就是个不可想象的巨大数字了。好在，一般来讲，具体的Permission项目不会特别多的。

该方案的关键，就在于Role和Resource表的LeftIndex和RightIndex这两个字段了，我们将使用这两个字段，在避免递归的情况下，实现较高性能的取某个继承节点的所有子元素或所有父元素的算法。

算法

我们以Role为例，首先Role表中有且只有一条记录存放所有Roles的顶层父节点（1，“Root Role”，1，2）。当他没有子节点时，其LeftIndex和RightIndex的值分别为1和2。当对其插入子节点时，LeftIndex和RightIndex的值需要做相应的调整，调整的规则如下（括号中为LeftIndex和RightIndex的值）：

按逆时针方向，大家能看出规则吗？

按照这个规则，我们可以如下获取某一个节点的所有字节点或所有父结点（使用伪SQL代码表示）：

获取ID为3的Role节点的所有的子结点包括本身：

SELECT * FROM Role WHERE

LeftIndex >= (SELECT LeftIndex FROM Role WHERE ID = 3)

AND

RightIndex <= (SELECT RightIndex FROM Role WHERE ID = 3)

注：如果要不包括ID=3的节点本身，只需要用>和<代替>=和<=。

获取ID为5的Role节点的所有父节点包括本身：

SELECT * FROM Role WHERE

LeftIndex <= (SELECT LeftIndex FROM Role WHERE ID = 3)

AND

RightIndex >= (SELECT RightIndex FROM Role WHERE ID = 3)

注：如果要不包括ID=5的节点本身，只需要用>和<代替>=和<=。

大家可以根据上面的图验证一下算法的效果。完全不需要递归，只需要简单的判断LeftIndex和RightIndex就行，性能自然是非常好的。

我们甚至可以以非常简单的SQL语句获得某一个ID为2的User对ID为6的Resource的PermissionsValue：

DECLARE @PermissionsValue int;

SELECT @PermissionsValue = @PermissionsValue | PermissionsValue

FROM PermissionsOfRole WHERE

RoleID IN

(

SELECT ID FROM Role WHERE

LeftIndex >= (SELECT LeftIndex FROM Role WHERE ID IN

(SELECT RoleID FROM UsersInRoles WHERE UserID = 2))

AND

RightIndex <= (SELECT RightIndex FROM Role WHERE ID IN

(SELECT RoleID FROM UsersInRoles WHERE UserID = 2))

)

AND

ResourceID IN

(

SELECT ID FROM Resource WHERE

LeftIndex <= (SELECT LeftIndex FROM Resource WHERE ID = 6)

AND

RightIndex >= (SELECT RightIndex FROM Resource WHERE ID = 6)

);

SELECT @PermissionsValue;

上面的SQL虽然有不少嵌套的SELECT，但是，因为子查询基本上都是对主键字段的条件判断，LeftIndex和RightIndex我们也会加上索引，因此，实际上不会对性能造成太大影响。

OK，查询性能很好，不过这是以新建或修改Role和Resource的层级关系时的一定的性能损失为代价的。每次新增或修改Role或Resource的层级关系时，必须按照前面所述的规则重置所有节点的LeftIndex和RightIndex值。不过，一般情况下，由于Role和Resource的维护操作占系统整体操作的比例很小，几乎可以忽略，因此其性能损失也不是什么大问题。具体的重置所有节点LeftIndex和RightIndex值的伪代码我就不贴出来了，大家稍微花费几个脑细胞就能想出来了^-^

//结束

2. Define Features according to Collected Requirements.

3. Define Entity Designs according to Defined Features.

4. Generate Entities, Configurations and Database Automatically from Entity Designs Using Code Generating Tools Provided by NBear.

3. Split Features into Clips from Presentation View Using Entities and Domain Objects (Value Objects).

4. Define MVP (Model/View/Presenter) Interfaces for Feature Clips using Entities.

5. Implement and Test Models, Views and Presenters asychronally Using Mock Tool to Simulate Implementations of Non-Implemented MVP Interfaces during separated development.

6. Integrate and Test MVPs in Together.

7. Finish.

Benefits When Using NBear

1. Minimize Manual Development and Maintenance Code Benefited from Code Generating Tool Provided By NBear.

2. Complete Team Parallel Development Support and Testable Presentaion Layer Benefited from MVP Pattern and NBear's MVP Components.

3. Strong Typed ORM (Object Relational Mapping) Support Benefited from NBear's Data Components. (No Manual Code or Configuration Needed.)

4. Strong Typed Distributed Support Benefited from NBear's IoC Components. (Configuration Only, No Manual Code Needed.)

5. Extended Web Helper Methods (String Formatter/AJAX/Client Script Factory, etc) to ASP.NET 2.0 Benefited from NBear's Web Components.

6. Transparent Code Generating and Database Synchronization in Visual Studio 2005 IDE Benefited from NBear's Visual Studio 2005 Code Generating Plugin.