(原创)系统架构设计-通用权限模型设计①

1.1前言
权限管理系统的应用者应该有三种不同性质上的使用,
A,使用权限  B,分配权限C,授权权限 
1.2初步分析
用户和角色 
说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表。这样就决定了一个人有什么样的权限。
做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情。因此再添加一个角色表,把某些人归为一类,然后再把权限分配给角色。角色属下的用户也就拥有了权限。
    用户、角色之间的关系是一个用户可以对应多个角色,一个角色可以对应多个用户。多对多关系。
所以需要一个中间表,相信大家都很熟悉,自然不会有疑问。
应用场景 

有了用户和角色以后,就需要设计应用场景,比如一个应用程序有几大模块(系统模块、项目管理模块、销售模块),

类似这样的模块就是一种应用场景,常见的还有 菜单 、 操作 等等。

假设现在我们设计好了,应用场景包括 模块、菜单、和操作,那么应该有以下六种关系

      1. 一个用户可以对应多个模块,一个模块可以对应多个用户。多对多关系。

      2. 一个用户可以对应多个菜单,一个菜单可以对应多个用户。多对多关系。

      3. 一个用户可以对应多个操作,一个操作可以对应多个用户。多对多关系。

      4. 一个角色可以对应多个模块,一个模块可以对应多个角色。多对多关系。 

      5. 一个角色可以对应多个菜单,一个菜单可以对应多个角色。多对多关系。  

      6. 一个角色可以对应多个操作,一个操作可以对应多个角色。多对多关系。
这样设计看起来没什么问题。是的,如果没有加入新的关系的话,这样是已经可以满足大部分的需求了。可是如果就是如果,新的关系(需求)往往会加入到系统进来。这个时候就需要再建立一个新的表。系统的复杂度也随着增加。

可以看出,这样的设计有几个问题:
      1. 数据表设计太复杂
       2. 应对系统方案过于固定
1.3一般的权限模型
用户,角色表,资源表之间是多对多的关系,这样的设计也可以实现权限但是会给t_resource和t_resource_role这张表随着系统中人员的增加数据量将会越来越多,不方便查询。

1.4把问题简单化后的权限模型

   不同的应用场合,你可能会想出不同的需求,提了一个新的需求以后,可能会发现原来的设计没方法实现了,于是还要添加一个新的表。这也是上面所提到的问题。 

 其实不必想得那么复杂,权限可以简单描述为:

   某某主体 在 某某领域 有 某某权限 

         1,主体可以是用户,可以是角色,也可以是一个部门

         2, 领域可以是一个模块,可以是一个页面,也可以是页面上的按钮

         3, 权限可以是“可见”,可以是“只读”,也可以是“可用”(如按钮可以点击)

   其实就是Who、What、How的问题,权限模型如下图所示。

    
转载请注明:www.xujin.org或www.virgocloud.com

posted on 2015-02-01 16:46  Software_King  阅读(201)  评论(0编辑  收藏

导航

统计