引言：本来园子里已经有不少RBAC方面的文章了，而且自己的这个系统也参考了其中一些朋友的思想和创意，考虑是不是还有发表的必要。但感觉虽然是同样的东西，由于每个人的出发点与目标都不相同，所以做出来的东西也不会是一样的。而且有些东西，我现在只是做出了架构设计，具体实现起来会不会很合适，也不太清楚。有园子里的弟兄们给提提建议，也是一件好事。是不是发在首页，也考虑了一下，感觉这篇文章，抛开质量不说，起码从字数上会对得起大家
。
正文部分
关于RBAC的基本理论，这里就不再多说了。
我是去年才接触RBAC这个概念的，许多东西了解的并不透彻，而且由于几年前就已经熟练使用Windows活动目录的权限管理系统了，因此一些理念和正宗RBAC观念会有一些出入，但应该不会对RBAC的主旨产生太大的影响。如果您觉得我加入的一些东西是多余的，或者感觉不习惯，欢迎提出看法，我会根据情况进行改进，谢谢。
其实开始并没有编写RBAC的想法，但是使用了微软的membership后，感觉很不顺手，兼容性、易用性、复用度等方面也感觉不适合自己。正好手上几个项目都涉及到了较为复杂的用户权限管理功能，因此年初决定用几个月的时间来专门做一下这个项目，即通过这个过程进行学习，也减轻一下以后的工作量。
因此，我写这篇文章也不是为了建立一个RBAC的范本，从理论上来供大家研讨，而是一切从实际出发，把我制作这个项目中的想法随着项目的进度写出来，在这个过程中探讨遇到的理论与技术点。
废话说得太多了，转入正题
要做RBAC，首先需要确定需求。开始是根据几个项目来考虑它们的共同点，看涉及到用户管理、权限验证的部分，那些是几个项目都需要实现的，哪些是某个项目所特有的，慢慢确立了RBAC的需求，决定了它要实现什么功能。
开始时，只想将项目从数据库建模开始，往上做到BLL这一层，然后其它项目可以使用此BLL，处理RBAC方面的工作，就相当于把几个项目的RBAC部分共享一样。
后来感觉如果只做到这一层的话，以后复用的话，工作量还是会很大。所以决定将后台管理部分的UI层也做出来。这样就相当于几个项目连界面部分也可以共享了。
然而在实际过程中，觉得即使做出了后台管理的UI。其它项目使用这个模块也会比较费事。而且这种模式，项目对RBAC的调用与调用项目内模块没什么区别。用户在使用RBAC项目时还是需要了解其内部的一些操作方法，耦合度太高，没有实现封装。
后来有了进一步的想法，能不能将其做成一个框架。虽然水平有限，说框架有些大，而且也不见得能做完美，但目标还是可以定得高一点么。
既然想做成框架，那就不是提供一个数据库模型，并完成相关的代码就了事的。我的想法就是，能够让用户在用脚本建立建立数据库，复制UI界面文件到项目文件夹，并引用dll后，无需再进行其它的配置工作，就能直接使用这套框架。用户自己编程进行RBAC操作时，只要一两个类就可以完成所有工作，对用户隐藏所有细节。
基于这种想法，我开始进行项目的建设，现在已经建立了下面几部分：
（1）BLL：业务逻辑层。
用于处理业务逻辑相关的工作，此层内容仅对RBAC项目内的成员开发，不提供对外调用。
（2）ClassFactory：类工厂。
当前仅支持数据访问层对象的创建。以后视需要增加新的工厂。
（3）Demo for WinForm：C/S模式界面模板
提供Windows程序的界面文件与操作代码，如果不想自己设计界面，可以直接使用此现成的界面文件。
（4）Demo for WebForm：B/S模式界面模板
提供Web项目的界面文件与操作代码。如果不想自己设计Web界面，可以直接使用此界面。否则只要制作新的CSS文件，替换原有css文件，即可实现自己的界面。
（5）IDAL：数据库访问层接口定义
没什么好说的
（6）Model：实体类
同样
（7）OracleDAL：Oracle 数据库访问层
支持Oracle数据库，这个准备先放一放，Oracle编程太不爽了
（8）Privilege Config Tools：权限配置工具
Windows程序，其它项目在使用此框架时，需要生成自己的的权限文件。这个工具就是用来做这件事情的。
（9）RBAC Manager：RABC管理类
这个是对外服务的部分，其它项目只要直接引用此dll，即可进行涉及到RBAC的各种操作。
（10）SQLServerDAL：SQL Server 数据库访问层
支持SQL Server数据库。也没什么好说的。
现在大家可以看出来了，作为最终用户，如果在项目中使用这个框架的话，那么他所要关心的只是RBAC Manger这一个namespace下的类的使用，而无需关住RBAC的细节。
项目组件说完了，再来介绍一下数据库建模
说明一下，为了保证大家都能看清楚图片，所以我把图片存得大了些，右边的几个表看不见，大家费点事另存到桌面上再看吧。
数据库建模图：
说一下各表的用途
所有表均以ksRBAC开头，避免与其它项目表重名。
（1）用户部分
ksRBAC_Users：用户基本表。此表仅存储最少量的用户信息，用于用户登陆、权限认证等常见的工作。
ksRBAC_UserMembership：用户权限表。此表用来存储涉及到权限系统工作的想关信息。
ksRBAC_UserDetail：用户基本信息表。用于存储用户的日常信息。只在查看用户资料时需要调用。
其实这个三表的内容完全可以放到一张表中，但感觉分到三个表里，在编程上会清晰一些。这里可能有不合理的地方，还望大家指正。
（2）权限部分
ksRBAC_ResourceGroups：资源分组。用于将同类资源进行分组，以方便管理，支持多级分类。
ksRBAC_Resources：资源。记录具体的资源对象。
ksRBAC_Operations：操作。记录具体的操作方法。
ksRBAC_Privileges：权限表。通过结成“资源-操作”对，来实现权限的定制。
（3）角色部分
ksRBAC_Roles：角色表。存储所有角色。
ksRBAC_PrivilegeInRoles：用户表，用于存储与身份验证有关的信息
ksRBAC_UsersInRoles：用户所属角色表。通过此表来设定用户具有那个角色的权限。
（4）分组部分
ksRBAC_Groups：分组表。存储分组相关信息
ksRBAC_GroupsInGroups：组属组表。设置分组所属的分组。
ksRBAC_GroupEstates：组状态类型表。
ksRBAC_UsersInGroups：组属用户表。设置用户所属组。
ksRBAC_UserInGroupEstates：组用户状态类型表。用于记录组中用户的状态。
（5）日志部分
这部分的内容还没有做完，因为现在还没有进展到涉及日志的操作，所以不能决定到底需要什么东西。
ksRBAC_UserLog：用户日志。用于记录用户操作
对于用户、权限、角色三部分的表，大家应该都没有什么疑问，稍微有些理解上的差异也也该是设计习惯不同造成的。感觉主要会在分组这一块有不同的理解。看了一些相关文章，也有涉及到分组设计的，但这些设计从功能上来讲相差甚远。有的是将分组与角色关联，相当于做了一个RoleGroups表，这种分组起到了分类角色的作用。有的是将分组作为一个组织结构架构来做，然后再与用户关联，这种分组起到了分类用户的作用。本项目中的分组，是与用户相关的，而与角色无关，它实现的是用户分类的功能。但分组在这里并不仅仅起到一个分类用户的功能，还有一个重要的功能，但因为每进行具体的代码编写，所以现在还不好说，我会在完善以后写出来的。
本来还有许多想写的，但是刚开始感觉思路上不是特别清晰，有些无从下笔，一些东西也不清楚是不是有必要说，就此打住吧。看看大家反馈，再决定需要写些什么内容吧。欢迎大家拍砖。
第一篇文章，其实并没有涉及到具体的技术细节，只是从整体上俯瞰一下这个项目。如果您没有用过RBAC，肯定会感觉到有些不知所云。以后我会在涉及到细节的地方详细讲解的。