在各种企业级系统开发的过程中难以避免都会遇到权限处理的设计。好的权限系统不但能为系统提供安全的解决方案，同时还能节约开发时间，提高系统的可维护性。
权限需求分为两类：
A、模块权限
操作功能模块的权限，或者访问菜单的权限。比如用户U有没有权利操作“发票界面”。
B、数据权限
数据权限是对访问数据范围的控制。
比如有1000张发票用户U有权利操作哪些发票的控制，是操作所有的发票还是自己创建的发票或者是自己部门的发票。
C、字段权限
在有些时候我们会对特殊字段设置权限，比如客户服务部是不可以看到客户合同额的。
D、操作权限
操作权限是用户对数据操作方式的控制，是创建、修改、删除或者其它特殊权限，如共享等。
操作权限一般是基于模块权限的。比如对用户U的发票模块操作权限的控制。但是有时候也会出现特殊情况，比如数据录入员可以创建所有的数据类型而不能浏览、修改、删除数据。
要创建适合自己项目的权限控制框架，需要根据自己项目需求来决定，适合自己的才是最好的，片面追求灵活与功能强大未必能给用户提供最佳体验。在决定使用什么权限框架的时候建议使用能满足自己项目需求的最简单的解决方案。
按需求分的话一般会有几种的等级出现。
1。固定角色
由系统提供固定的几种角色，这样的系统一般需求比较稳定，变化较少。比如论坛，提供管理员、版主、会员、非会员几种简单的角色进行权限的控制，就足够适应需求。使用这种方式由于角色固定，我们就可以在代码中采用硬编码，所以控制角色权限也好、控制数据权限也好都会比较简单。这种控制方式简单有效，能在最短的时间内提供很好的安全控制。编码简化不仅仅会降低开发成本，同时也会降低维护成本，更重要的用户操作也会简化，易用性明显提高。
如果你的系统使用这种方式就可以解决问题那么绝对不提倡使用其它的解决方案。很多同事都会说这样如果遇到需求变化不就会经常的需要修改代码吗？需求是层出不穷的，为了未可知的需求去大动干戈，在一些未必会发生的事情上浪费你的宝贵时间我认为是非常不值得的。能够满足一段时间内的需求同样可以称为一个好的系统。
当然，如果你能明确的知道在未来不长的时间内这种方式并不能满足你的需求的话，可以考虑下面的方案。
2。动态角色：
很多项目并不是几种固定的角色就能满足系统要求。由于企业经营方式的改变可能会设置更多的岗位，更多的岗位带来更多的角色需求。这时候采用固定角色就非常的失策。
a、模块权限：
创建动态角色来控制模块权限并不复杂。我们只需要几个表“功能表”“角色功能表”“用户角色表”就可以实现我们的系统。
b、数据权限
数据权限的控制，一般会与组织结构相关。在微软的CRM中数据权限被分为全局、部门、下属机构、 拥有等几种。
全局：所有数据
部门：当前部门的数据，不包括下属机构。
下属机构：下属机构的数据，不包括本部门。
拥有：自己拥有的或者创建的。
具体范围等级的划分也需要根据自己项目需求的不同而具体对待。比如，全局、下属人员、自己等。
c、字段权限
字段权限的控制属于权限控制中最繁琐的控制，因为字段权限的控制往往会脱离权限控制的范畴影响界面布局。
字段权限一般是依托与模块权限的，我们需要设置“模块字段表”，与“角色模块字段表”来存储角色拥有的字段权限范围。
d、操作权限
操作权限是对具体某种用户操作权限的控制，操作权限的控制往往也依托于模块权限，偶尔会有特例。
不基于模块的操作权限相对简单，只需要对操作权限设置“角色操作表”做单独处理即可。
基于模块的操作权限的控制相对复杂，需要设置“模块操作表”来维护模块拥有的操作类型，同时设置“角色模块权限表”来控制角色拥有的模块操作范围。
（ 注：上面提到的各个表只是举例，并非什么经典设计。）
事情往往会比上面列出的各种情况更复杂，当各种权限纠集在一起就变得更棘手。
例如在CRM中就会出现同时并存的情况，首先是基本的动态角色权限，然后是基于角色的模块权限，然后是基于模块权限的操作权限，又有与模块权限交错的数据权限，再加上让人头疼的字段权限。我们就陷入了一片苦海。
最后还是要提醒各位同行在开始您的设计之前一定要搞清楚自己的项目需求，只有依托于需求的设计才能是好的设计，更不会白白浪费你的汗水。千万不要迷失在追求全能的理想境界之中。
ps:以上只是本人的一点看法，如有遗漏错误还请指正。至于更详细的表设计和代码实现在有时间的时候本人尽力奉上。
（原创，转载请注明出处。）