关于菜单授权与功能授权关系思考

    严格说从授权的角度来讲菜单授权与功能授权没有任何关系,它们其实是两类资源的独立授权,之所以将这两类授权放在一起
来进行分析,主要是从实际设计角度出发,大部分的设计者其实应该都碰到过,或者纠结过,也思考过如何建立自己的授权体系,而且
不自觉的将菜单授权与功能授权混合在一起,甚至一个系统完成,授权体系也完成,但是最终还是没有搞清楚自己的系统授权是怎样的
一种结构,下面就来分析一下为什么很多设计设计喜欢将两个独立的授权搞到一起.
    所谓授权其实就是建立resource与owner之间的关系,这里的resource可以是任何东西,比如一串普通的字符也可能是一个
URL地址,如果是记录级授权那么这里的授权其实就是实体的标识.至于授权完成之后被授权的资源用来做什么,这就与业务相关了,
比如菜单授权主要用在了UI的展示控制上,功能授权主要用在了拦截器安全控制上,具体到菜单授权模型,是一种混合型授权,
相对来说比较复杂,如果将菜单授权与功能授权进行独立设计,那么菜单授权将会变得要简单很多,但有以下几个因素必须考虑
    1.如果分离,那么授权必须在两个功能模块中进行管理;
    2.功能授权授权与菜单授权在一定程度上存在一定的制约关系,比如通过菜单授权,通常是需要制定提取数据的功能,否则菜单授权没有意义;
    3.功能授权的资源其实非常简单,就是简单的URL,因此功能授权没有必要将一条记录作为功能的对等资源,其实一条记录可以对应一组资源;
    
    考虑到上面几个因素,其实我认为将功能授权放在菜单授权的内部可能会更加好,只是这样的功能授权不是很直观,这样你可以通过
菜单授权达到多种授权的目的,这样设计的一个前提是除去菜单授权之外其他的授权资源只是一个简单的字符串,如功能授权的资源只是
一个简单URL,另外还有像其他一些抽象业务授权也是可以进行类似处理的,看下面的一个设计方案:
    
    菜单标识                菜单抽象信息                        授权扩展信息
    me