从刚入行一直到现在，经历了许多项目也实际开发了很多系统，经历过的权限管理设计也是形形色色，按照接触的先后顺序，可以作如下总结。

1.硬编码

硬编码可谓是简单粗暴，是对需求最直接的转换。甲方说有三类人，我就直接设定这三类人，而且这三类人看到的页面，页面上所具有的元素都是定死的。不同的用户登录进来，按照设定直接跳转到指定的首页，然后按照固定的链接导航到不同的功能页面去。简单，非常简单，根本不用费脑子，适合一锤子买卖，之后即使再给钱也不给改的系统。缺点也是显而易见的，根本毫无灵活性可言，要是蹦出个第四类人，这工作量想想就头疼。这种设计就是垃圾，不过在我刚工作那阵也是经常见到的。

2.菜单控制

要说上面那个垃圾，那么这个也好不到哪去，就是掩耳盗铃，防君子不防小人的设计。不过直到去年，我在面试的时候，仍旧有人会抛出这种设计，甚至于不知道这种设计的危害。这种设计我觉的根本没有优点只有缺点，看似有门，其实只有个门框，连围墙都没有，简直就是不设防。

3.URL控制

从工作到现在，这种控制是用的最多的，只不过原来是只控制到这一层，现在会控制到下一层。如果不考虑颗粒度的大小，这种控制其实已经足够灵活，也足够安全了。这种方式对于一些小型系统完全够用了，因为小型系统无非就是希望某人看到某些页面，某人看不到某些页面而已。但是对于一些稍显复杂的系统，这种控制就不够灵活了。

比如有一个页面，有两个人A和B，A具有创建权限，B具有只读权限，A和B都能访问此页面，但是A可以看到此页面上的创建按钮，而B看不到此按钮。如果要完成这种需求，单单使用URL控制的话，就需要做两套页面，分别赋予这两个人。资源就显得冗余，如果未来需要修改页面的话，同样的工作需要做两遍，不够灵活。

4.元素控制

上面的案例，其实就需要用到页面元素控制。将页面上所有的HTML标记视为资源，控制资源的显隐、读写，从而达到控制人员使用权限的目的。页面元素是资源、URL是资源，所以一个基本的权限框架至少应该能够控制这两种资源，先验证人员是否能够访问此URL，再验证是否能够使用某些资源。结合上面的案例，可以只做一个页面，A和B都能够访问此页面，将页面上的创建按钮视为一个页面资源，A具有使用此资源的权限，B没有使用此资源的权限，所有的工作只做一遍，增加了权限控制的灵活性，同时减少冗余。

5.数据权限

上面所说的都是功能权限，一个一个的功能其实是由一个一个的页面和页面所承载的资源来体现的。但是数据权限和功能权限不太一样，功能权限有可能做成一个通用的框架，成为一种理念。但是数据权限我个人觉的很难做到通用，因为数据权限与系统的数据库设计和业务的耦合度是相当高的，不同的用户使用某一个业务方法的输入看似都一样，但是其内在处理可能大相径庭，有可能使用的数据表不同，有可能使用的过滤条件不同。从目前的情况来看，我觉的数据权限如同业务逻辑一样，硬编码占大多数，只能交由程序员来做控制，也只能尽量做的灵活，这方面我还没有总结归纳出一套行之有效的办法，只能视需求而定。