权限组件设计计划表

准备写一个通用的权限组件。这个组件分3步来实现。

1.设计数据库表

2.抽象出接口

3. 代码实现（C#+SQL 2005版本）

1. 通用思路：用户-》角色-》权限-》资源

  如何解释资源和权限，比如一个网页和read，那么read就是查看权限，网页是资源， 首先是用户想要查看这个网页，那么就要看这个用户有read  权限没有，还要看这个用户拥有这个资源没，举个列子： 比如国家给了你土地，你就拥有了 土地和使用土地的权限，但是你没有把这个土地资源卖给 别人的权限， 就像 你接某个人的东西，你自然就拥有了使用权限，但是没有卖于他人的权限，具体的我们的软件，举个数据库的列子，表就是资源，对应的权限有select ,insert ,update, deleete。

 

  这儿有2个问题需要考虑： 角色 到底需要设计成 继承不？

                                    角色的创建和确定是在哪个时候确定的（系统开发阶段，系统使用阶段），是由谁来确定的？（开发人员，系统管理员）

 考虑到降低复杂性，我准备不采用角色继承的方式

 至于角色的创建，我决定应该2种方式并行，系统在开发阶段提供一些基本的角色，然后允许管理员在系统运行的时候添加新的角色来满足新的要求。

 另外一个关键的问题是 权限到底是指的什么，我觉得是包含这个系统的一切。比如基本的数据库表的insert,select ,updatem,delete权限，

 还有其他的文件浏览权限，这个权限的明确 就需要在系统设计的时候搞清楚。大概分为系统访问权限，数据权限。 就像操作系统一样，你有登录这个操作系统的权限没，登录了表示有访问权限了，但是登录系统，如果你要看一个文件，那么还要验证你有查看这个文件的权限没，对比我们的软件系统就登录权限，有没有点击删除，更新，查看，插入的权限没。

那么这个权限验证是 在什么地方验证的，比如就拿三层B/S机构的系统来说吧，是在UI层，还是该在BS，还是该在DAL层 进行验证呢？

那么要看权限具体是什么了，比如是buttonID,就 表示你有个点击这个按钮的操作权限没有，这儿这个权限就是一个功能，就相当于一个司令才有喊开战的权限一样，其实这个例子的权限有继承功能的，比如班长能指挥自己手下的士兵，但是如果司令要指挥一个士兵就必须通过班长，然后班长才下达命令，但是司令也可以直接命令士兵，呵呵 看这个士兵买不买帐，就如古语：天高皇帝远！

这个权限验证 不是我们讨论的范围，说了这么现在给出数据库关系图：