标签：控件 框架 角色 记录 正向 权限 int410 节点 表组
角色：“正向角色”、“拒绝角色”。资源角色：“资源过滤方案”。涉及到了角色，请大家多提意见。
继续，这是第四章了。这里涉及到了资源方面的，不过有点绕，所以这里先介绍一下表结构，在后面的章节里面，再举例子详细介绍。
通用权限想要写的文章目录：（这是第四章）
1、 简介、数据库的总体结构
2、 介绍人员表组
3、 介绍组织结构表组
4、 介绍角色表组
5、 介绍“项目自我描述表组”
6、 权限到节点
7、 权限到按钮
8、 权限到列表（表单、查询）
9、 权限的验证
10、 资源方面的权限
11、 角色管理的程序（给客户用的）
12、 权限下放
13、 个性化设置
A、、 【自然框架】之通用权限（外传）：杂谈
角色表组
目前有七个表：（有四个是这两天才加上的）
一、Role_Roles ，记录角色信息，比如角色名称、角色描述、角色拥有的节点等。这个表我也打算可以做成n级分类的形式，因为如果角色多了（比如几百个），不分类的话，看起来就比较乱，但是如何来分类我又没有想好。当然对于一些简单的情况，也是可以不分类的。
这个角色表Role_Roles记录的是操作方面的，并不包含资源方面。这个角色分为两种：正向角色、拒绝角色。
1、正向角色：
记录可以做的权限，就是记录下来可以做哪些操作，正向角色不能继承，不能关联，但是可以组合。如果一个人拥有多个正向角色，那么只要有一个角色里面允许，那么他就可以做这个操作。
2、拒绝角色：
和正向角色相反，他记录的是不可以做的操作。拒绝角色必须“继承”（或者叫做关联）一个或多个正向角色。拒绝角色不能继承拒绝角色。如果一个人拥有了一个拒绝角色，那么拒绝角色里面不允许做的操作就绝对不可以做，不管他拥有的其他的正向角色是如何规定的。
至于给人员分配角色的时候如何来具体的区分，还没有太完善。
3、“FunctionIDs”：角色拥有的节点的字段。这个字段的内容是“1,2,3,4”的形式。对于正向角色来说这里记录的就是可以操作的节点，而对于拒绝角色来说，这里记录的就是不可以操作的节点。
这个也是“权限到节点”的关键字段。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| RoleID | 角色 | int | 4 | 1 | 0 | 主键 |
| RoleName | 角色名称 | nvarchar | 50 | _ | 0 | 角色名称 |
| RoleDescribe | 角色描述 | nvarchar | 50 | _ | 0 | 角色描述 |
| RoleKind | 角色类型 | int | 4 | 1 | 0 | 1：正向角色；2：拒绝角色 |
| LinkRoleIDs | 关联角色 | nvarchar | 50 | _ | 0 | 拒绝角色有效。 拒绝角色可以关联多个正向角色，但是不能关联拒绝角色。 正向角色不能关联。 |
| ParentID | 父节点ID | int | 4 | 1 | 0 | 父节点ID。为n级分类做预留 |
| ParentIDPath | 父节点ID的路径 | nvarchar | 30 | _ | 0 | 父节点ID的路径。为n级分类做预留 |
| RoleLevel | 角色层数 | int | 4 | 1 | 0 | 第几级的角色 |
| Sort | 排序 | int | 4 | 1 | 0 | 序号 |
| FunctionIDs | 节点 | nvarchar | 500 | _ | 0 | 角色拥有的功能节点。1,2,3的形式 |
| AddedDate | 添加日期 | smalldatetime | 4 | GetDate() | 0 | 记录添加日期 |
| AddedUserID | 添加人 | int | 4 | 1 | 0 | 记录哪个用户添加的 |
| UpdatedDate | 最后修改日期 | smalldatetime | 4 | GetDate() | 0 | 记录最后修改日期 |
| UpdatedUserID | 最后修改人 | int | 4 | 1 | 0 | 记录哪个用户最后修改的 |
二、Role_RoleButton ，这个表要记录一个节点里的按钮的权限，就是说一个角色拥有的节点里的按钮的权限。如果他和正向角色关联，则说明可以使用这个按钮，如果和拒绝角色关联则说明不能使用这个节点。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| RoleID | 角色 | int | 4 | 1 | 0 | 主键 |
| FunctionID | 节点 | int | 4 | 1 | 0 | 外键 |
| ButtonIDs | 人员ID | nvarchar | 200 | _ | 0 | 外键 |
三、Role_RoleColumn，同上，这个表要记录一个角色拥有的节点里的列表、表单或者查询的字段的权限。如果粒度不需要做得这么细的话，那么这个表就可以省略了。
同样如果他和正向角色关联，则说明可以使用这些字段，如果和拒绝角色关联则说明不能使用这写字段。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| RoleID | 角色 | int | 4 | 1 | 0 | 联合主键 |
| FunctionID | 节点 | int | 4 | 1 | 0 | 联合主键。外键 |
| Kind | 类型 | int | 4 | 1 | 0 | 1：列表；2：表单；3：查询 |
| ColumnIDs | 字段ID | nvarchar | 200 | _ | 0 | 外键 |
四、Role_RoleUser，角色里的用户，角色和用户是多对多的关系，即一个人可以有多个角色，一个角色可以有多个用户，角色和UserID关联，但是也要加上PersonID的信息。
一个人可以拥有多个正向角色，也可以拥有多个拒绝角色。拒绝角色优先，只要拒绝了那么就不可以使用。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| RoleUserID | 编号 | int | 4 | 1 | 0 | 主键 |
| RoleID | 角色 | int | 4 | 1 | 0 | 外键 |
| UserID | 用户 | int | 4 | 1 | 0 | 外键。角色里面拥有的账号ID |
| PersonID | 人员 | int | 4 | 1 | 0 | 外键。角色里面拥有的用户ID |
五、Role_ResourceListCase，“记录列表”的资源过滤方案，就是记录过滤条件，即SQL语句里面的Where后面的查询条件。这个是给GridView级别的控件准备的，在自然架构里面可以给QuickPager的查询条件的属性赋值。这样就可以实现过滤的效果。这个只有“正向”没有“拒绝”。角色和功能节点起到“联合主键”的功能，一个节点可以有多个方案以供选择。但是一个角色和节点的组合只能选择一个方法。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| ListCaseID | 编号 | int | 4 | 1 | 0 | 主键 |
| FunctionID | 关联节点 | int | 4 | 1 | 0 | 外键。0：不限制节点；其他：有效的节点 |
| ResourceName | 资源角色名称 | nvarchar | 50 | _ | 0 | 资源角色名称 |
| ResourceDescribe | 资源角色描述 | nvarchar | 50 | _ | 0 | 资源角色描述 |
| SQL | 过滤条件 | nvarchar | 200 | _ | 0 | SQL语句里的where后面的查询条件 |
| ParentID | 父节点ID | int | 4 | 1 | 0 | 父节点ID。为n级分类做预留 |
| ParentIDPath | 父节点ID的路径 | nvarchar | 30 | _ | 0 | 父节点ID的路径。为n级分类做预留 |
| ResourceLevel | 资源角色层数 | int | 4 | 1 | 0 | 第几级的角色 |
| Sort | 排序 | int | 4 | 1 | 0 | 序号 |
| AddedDate | 添加日期 | smalldatetime | 4 | GetDate() | 0 | 记录添加日期 |
| AddedUserID | 添加人 | int | 4 | 1 | 0 | 记录哪个用户添加的 |
| UpdatedDate | 最后修改日期 | smalldatetime | 4 | GetDate() | 0 | 记录最后修改日期 |
| UpdatedUserID | 最后修改人 | int | 4 | 1 | 0 | 记录哪个用户最后修改的 |
六、Role_ResourceControlCase ，控件的资源过滤方案，就是记录过滤条件，即SQL语句里面的Where后面的查询条件。这个是给下拉列表框级别的控件准备的。通过这里的条件可以达到过滤数据的效果。同样，这个也有“正向”没有“拒绝”。
1、一个控件（比如下拉列表框）可以有多个方案，也可以不使用方案，即显示全部数据。
2、一个资源方案只能给一个控件使用。
3、一个功能节点里面有查询和表单，而一个表单（查询）里面有可能有多个下拉列表框。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| ControlCaseID | 编号 | int | 4 | 1 | 0 | 主键 |
| ColumnID | 关联控件 | int | 4 | 1 | 0 | 外键。关联的控件，即字段 |
| ResourceName | 资源角色名称 | nvarchar | 50 | _ | 0 | 资源角色名称 |
| ResourceDescribe | 资源角色描述 | nvarchar | 50 | _ | 0 | 资源角色描述 |
| SQL | 过滤条件 | nvarchar | 200 | _ | 0 | SQL语句里的where后面的查询条件 |
| AddedDate | 添加日期 | smalldatetime | 4 | GetDate() | 0 | 记录添加日期 |
| AddedUserID | 添加人 | int | 4 | 1 | 0 | 记录哪个用户添加的 |
| UpdatedDate | 最后修改日期 | smalldatetime | 4 | GetDate() | 0 | 记录最后修改日期 |
| UpdatedUserID | 最后修改人 | int | 4 | 1 | 0 | 记录哪个用户最后修改的 |
七、Role_RoleResource，角色、节点、资源方案的关系。
这是一个关联表，把角色、和资源方案关联起来，由于一个角色里面会有多个功能节点，一个功能节点可能有多种方案（但是只能选一个），有一个表单、有一个查询，而表单和查询里面会有多个下拉列表框这一类的控件， 所以在关联的时候是角色和功能节点做联合主键的作用。好像没说明白，暂时先这样吧，以后我举几个例子就好办了。
| 字段名 | 中文名 | 字段类型 | 大小 | 默认值 | 是否空 | 说明 |
|---|---|---|---|---|---|---|
| RoleResourceID | 编号 | int | 4 | 1 | 0 | 主键 |
| RoleID | 角色 | int | 4 | 1 | 0 | 外键 |
| FunctionID | 节点 | int | 4 | 1 | 0 | 外键 |
| ListCaseID | 列表过滤方案 | int | 4 | 1 | 0 | 外键，给分页控件的查询条件用 |
| ControlCaseID | 控件过滤方案 | nvarchar | 200 | _ | 0 | 1,2,3的形式，下拉列表框级别的控件用 |
角色表组里面涉及到了“FunctionIDs”、“ButtonIDs”、“ColumnIDs”三个字段，这三个字段就是“项目描述”里面的，“FunctionIDs”即功能节点的ID，“ButtonIDs”即功能按钮（比如添加、修改、删除等）的ID，“ColumnIDs”即字段的ID，也可以说是控件ID，因为一个字段都可以对应一个控件。可能您看着有点晕，不要着急，下一章写完了，您就不会晕了。
标签：控件,框架,角色,记录,正向,权限,int410,节点,表组 来源： https://blog.51cto.com/u_15179455/2729994
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。