有几种调控方法

其中最常用的方法是按模块控制权限

换句话说只要有了这个模块的权限，就有了模块内所有的权限（例如有管理员工资料权限的人就拥有增删改查管理员工资料的权限等等，在操作上就不再划分）

还有一种是按操作划分权限

这个就麻烦一点

每个功能都是一套操作

只有拥有权限的人才能进行操作

你的属于后一种

然后在程序里实现的时候

会有一个全局的权限控制类

调用用户登录的时候的权限信息并判断是否有权限

而判断的地方应该是在全局的页面入口处（例如web开发，所有的管理页面都继承一个master页面，有一个模块id，所以判断用户权限的地方就应该是在全局的master页面里面）

最近在用枚举做一个多模块可扩展的权限的东东，细分的倒是不错，但是判断权限的时候重载和扩展都好头痛。现在还没有完美解瘊。

“RBAC的模型设计了权限管理系统”

我是很清楚这个模型，不过我在做权限设计的时候如下：

设计基权和域

基权也就是你理解的“读，写，删...”基权也应该是可以扩展的，假设有了“文件发送”

域就是自己定义的范围人为的定义划分也是自定义的

完成以上思想后再基本上是划分为 应用权限 和 数据权限

在此之上还需要角色的管理（可以交集）

定义统一接口进行扩展，数据权限则要实现接口并特殊处理，不同的数据要求所需的数据是不同的。

数据权限不管是什么应用程序都是一样的，也是要通过代理程序去做选择和处理

不同的权限有不同的功能类去处理，数据返回则需要委托来CallBack

例:一个.net的Web应用程序

那么我在原有的基础上构架一个针对.net的Web应用程序解决方案。

如页面中的一些控件所属的域，在Web统一通过程序处理这些控件（如禁用，启用，不可见等）

"例如需要业务经理能看到业务部所有员工添加的客户信息":这是典型的商业逻辑，不是经典的权限管理部分，当然，就功能而论，确实属于权限管理部分。

就实用来说，我宁愿将 权限管理 分为三个层次：

1、控制菜单的可见性。什么样的Role可以访问哪些菜单，主要是从大的功能方面分，比如，业务员对某些财务的菜单项是不可见的。

2、经典的（或者说狭义的）RBAC模型所处理的权限管理， 就是你所说的 ：读、写、删、运行、创建。

3、业务级别的权限管理。这个要做为商业逻辑来处理，别再按照 权限管理的思路做，比如一个部门的人，只能访问本部门的信息，不可访问其他部门的信息。就像你所用的：select * from customer where ownerId=x。这其实与用户组的功能类似。

权限划分有两种：

一种模块划分，就是给角色分配模块

第二种功能划分，把用户分为几种分配不同的操作。

你还可以吧这两种混合起来使用。

这个设计在anycmd里。推荐你看看这个开源项目。

这样一段话可能对你有帮助：

组织结构是对资源的单元划分，组织结构节点是边界，每一个边界绑定的角色应该只在当前用户进入这个边界后激活离开这个边界后收回，从而不能将从一个边界内得到的角色带出这个边界去操作其他边界内的资源。

Anycmd是一个.net平台的完全开源的，完整支持RBAC的（包括核心RBAC、通用角色层次RBAC、静态职责分离RBAC和动态责任分离RBAC），将会支持xacml的通用的权限框架、中间件、解决方案。完整的RBAC规范所定义的能力只是anycmd所提供的能力集的一个子集。

权限系统干了什么？

给出一套方法，将系统中的所有功能标识出来，组织起来，托管起来，将所有的数据组织起来标识出来托管起来， 然后提供一个简单的唯一的接口，这个接口的一端是应用系统一端是权限引擎。权限引擎所回答的只是：谁是否对某资源具有实施 某个动作（运动、计算）的权限。返回的结果只有：有、没有、权限引擎异常了。