在各种企业级系统开发的过程中难以避免都会遇到权限处理的设计。好的权限系统不但能为系统提供安全的解决方案，同时还能节约开发时间，提高系统的可维护性。
权限需求分为两类：
A、模块权限
操作功能模块的权限，或者访问菜单的权限。比如用户U有没有权利操作“发票界面”。
B、数据权限
数据权限是对访问数据范围的控制。
比如有1000张发票用户U有权利操作哪些发票的控制，是操作所有的发票还是自己创建的发票或者是自己部门的发票。
C、字段权限
在有些时候我们会对特殊字段设置权限，比如客户服务部是不可以看到客户合同额的。
D、操作权限
操作权限是用户对数据操作方式的控制，是创建、修改、删除或者其它特殊权限，如共享等。
操作权限一般是基于模块权限的。比如对用户U的发票模块操作权限的控制。但是有时候也会出现特殊情况，比如数据录入员可以创建所有的数据类型而不能浏览、修改、删除数据。
要创建适合自己项目的权限控制框架，需要根据自己项目需求来决定，适合自己的才是最好的，片面追求灵活与功能强大未必能给用户提供最佳体验。在决定使用什么权限框架的时候建议使用能满足自己项目需求的最简单的解决方案。
按需求分的话一般会有几种的等级出现。
1。固定角色
由系统提供固定的几种角色，这样的系统一般需求比较稳定，变化较少。比如论坛，提供管理员、版主、会员、非会员几种简单的角色进行权限的控制，就足够适应需求。使用这种方式由于角色固定，我们就可以在代码中采用硬编码，所以控制角色权限也好、控制数据权限也好都会比较简单。这种控制方式简单有效，能在最短的时间内提供很好的安全控制。编码简化不仅仅会降低开发成本，同时也会降低维护成本，更重要的用户操作也会简化，易用性明显提高。
如果你的系统使用这种方式就可以解决问题那么绝对不提倡使用其它的解决方案。很多同事都会说这样如果遇到需求变化不就会经常的需要修改代码吗？需求是层出不穷的，为了未可知的需求去大动干戈，在一些未必会发生的事情上浪费你的宝贵时间我认为是非常不值得的。能够满足一段时间内的需求同样可以称为一个好的系统。
当然，如果你能明确的知道在未来不长的时间内这种方式并不能满足你的需求的话，可以考虑下面的方案。
2。动态角色：
很多项目并不是几种固定的角色就能满足系统要求。由于企业经营方式的改变可能会设置更多的岗位，更多的岗位带来更多的角色需求。这时候采用固定角色就非常的失策。
a、模块权限：
创建动态角色来控制模块权限并不复杂。我们只需要几个表“功能表”“角色功能表”“用户角色表”就可以实现我们的系统。
b、数据权限
数据权限的控制，一般会与组织结构相关。在微软的CRM中数据权限被分为全局、部门、下属机构、 拥有等几种。
全局：所有数据
部门：当前部门的数据，不包括下属机构。
下属机构：下属机构的数据，不包括本部门。
拥有：自己拥有的或者创建的。
本内容试读结束，登录后可阅读更多
下载后可阅读完整内容，剩余1页未读，立即下载
