公司系统中的菜单功能和权限功能

在到过几家公司上班，都有见到类似的菜单和权限的设计，先看图



这个是应用的界面图。这种设计和我以前的理念有很大区别，我对设计菜单和权限时候，会绝对的把菜单和权限看成是两个完全没有直接关系的模块，权限是权限，菜单是菜单。如，权限查看学生，只是一个表示STUDENT_VIEW，而这个权限具体到能干嘛，它本身不知道。然后它和角色关联起来后，那么属于这个角色的用户，就自然而然的拥有了STUDENT_VIEW这个权限了，但是这个时候，对于权限本身能完成那些工作，依然是未知的。

随后比如在一个实际的查看学生，搜索学生等等功能，都会验证当前用户是否具有这个权限。

而菜单实际上和权限之间是隔离的，基本上不需要知道权限。当然有个特殊的情况就是菜单要求不具备执行该功能的权限，那么就不显示，那这也只是在显示菜单之前，做一次验证是否有某个权限，然后绝对要不要显示而已。

而对于这类设计，则很是迷惑。通过不断查看这类设计的代码，算了明白了怎么回事了。

以在北京某家公司的设计为例（其他公司的应该也类似），具有一张表permission（权限ID，应用ID【应用ID的作用将会在我理解了应用管理之后，发表新的文章解释】以及一个链接字段URL），这里可以看到的是，权限实际上就已经是某个链接了。

然后是菜单（要理解这种理念，就必须要先理解权限，然后是菜单，最后才是角色），菜单的基本属性之类的则不解释了，关键在于这种设计中，菜单的链接是无法设置的，是通过菜单把权限关联起来（在功能使用的时候，是通过导入应用入口的功能来和实际的某条permission联系起来），通过权限，来得到URL。

角色，这个时候菜单才是角色所具有的权限（上面说的permission表并不是角色所直接拥有的权限关系了）。

第一种理念个人更加推荐使用，举个两种理念的区别：
查看某个学生详细信息和搜索学生记录，都需要具有STUDEN_VIEW权限
那么第一种理念就更加易于使用

而第二张实际上链接才是真正的权限，那么查看某个学生详细信息和搜索学生记录实际上是两个URL，这个角色就必须同时具有这两个链接的菜单的权限。而第一种理念也更加符合单一原则和RBAC（Role-Based Access Control，基于角色的访问控制）的设计方式。

评论

1 楼 weituotian 2016-10-10  

说的不好,没人看的