1.讲的很详l?br />http://www.cnblogs.com/Gavinzhao/archive/2009/11/10/1599691.html
实现业务pȝ中的用户权限理--设计?/span>
B/Spȝ中的权限?/span>C/S中的更显的重要,C/Spȝ因ؓhҎ的客LQ所以访问用L权限可以通过客户端实现或通过客户?/span>+服务器检实玎ͼ?/span>B/S中,览器是每一台计机都已具备的,如果不徏立一个完整的权限,那么一?/span>“非法用户”很可能就能通过览器轻易访问到B/Spȝ中的所有功能。因?/span>B/S业务pȝ都需要有一个或多个权限pȝ来实现访问权限检,让经q授权的用户可以正常合法的用已授权功能Q而对那些未经授权?/span>“非法用户”会他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满_部分B/Spȝ中对用户功能权限控制的权限系l?/span>
需求陈qC同职责的人员Q对于系l操作的权限应该是不同的?/span>优秀的业务系l,q是最基本的功能?/span>
-
- 可以?/span>“l?/span>”q行权限分配。对于一个大企业的业务系l来_如果要求理员ؓ其下员工逐一分配pȝ操作权限的话Q是件耗时且不够方便的事情。所以,pȝ中就提出了对“l?/span>”q行操作的概念,权限一致的人员~入同一l,然后对该l进行权限分配?/span>
- 权限理pȝ应该是可扩展?/span>。它应该可以加入CQ何带有权限管理功能的pȝ中。就像是lg一L可以被不断的重用Q而不是每开发一套管理系l,p针对权限理部分q行重新开发?/span>
- 满业务pȝ中的功能权限?/span>传统业务pȝ中,存在着两种权限理Q其一是功能权限的理Q而另外一U则是资源权限的理Q在不同pȝ之间Q功能权限是可以重用的,而资源权限则不能?/span>
关于设计
借助NoahWeb的动作编E理念,在设计阶D,pȝ设计人员无须考虑E序l构的设计,而是从程序流E以及数据库l构开始入手。ؓ了实现需求,数据库的设计可谓及其重要Q无论是“l?/span>”操作的概念,q是整套权限理pȝ的重用性,都在于数据库的设计?/span>
我们先来分析一下数据库l构Q?/span>
首先Q?/span>action表(以下UCؓ“权限?/span>”Q,gorupmanager表(以下UCؓ“理l表”Q,以及master表(以下UCؓ“人员?/span>”Q,是三张实体表Q它们依ơ记录着“权限”的信息,“理l?/span>”的信息和“人员”的信息。如下图Q?/span>
q三个表之间的关pL多对多的Q一个权限可能同时属于多个管理组Q一个管理组中也可能同时包含多个权限。同L道理Q一个h员可能同时属于多个管理组Q而一个管理组中也可能同时包含多个人员。如下图Q?/span>
׃q三张表之间存在着多对多的关系Q那么它们之间的交互Q最好用另外两张表来完成。而这两张表v着映射的作用,分别?/span>“actiongroup”?/span>Q以下简U?/span>“权限映射?/span>”Q?/span>?/span>“mastergroup”?/span>Q以下简U?/span>“人员映射?/span>”Q?/span>Q前者映了权限表与理l表之间的交互。后者映了人员表与理l表之间的交互。如下图Q?/span>
另外Q还需要一张表来控制系l运行时左侧菜单中的权限分栏Q也是“权限分栏?/span>”Q如下图Q?/span>
Ҏ上面的分析,我们q行数据库结构设计,如下图:
Z能够q行良好的分析,我们数据库l构图拆分开来,三张实体表的作用已经很清晎ͼ现在我们来看一下两张映表的作用?/span>
一权限映射?/span>如下图:
首先Q我们来了解一?/span>权限映射?/span>?/span>理l表以及权限?/span>之间的字D关联?/span>
看图中的U圈Q先?/span>gorupid字段相关联,q种兌方式在实际数据库中的表现如下图:
如图中所C,理l表?/span>“理?/span>”?/span>groupid?/span>1Q那?/span>权限映射?/span>?/span>groupid?/span>1的权限也是“理?/span>”所拥有的权限?/span>
使用groupid字段兌Q是Z查到一个管理组能够执行的权限有哪些。但q些权限的详l信息却?/span>action字段兌所查询到的?/span>
action字段相关联在数据库中的表现如下图Q?/span>
通过q种兌Q才查询?/span>权限映射?/span>之中那些权限的详l信息。综合v来,我们q道了一个管理组可以执行的权限有哪些Q以及这些权限的详细信息是什么?/span>
或许你会问,Z么不使用actionid字段相关联呢Q因为:
- 权限?/span>中的id字段在经q多ơ的数据库操作之后可能会发生更改?/span>
- 权限映射?/span>中仅仅记录着一个管理组可以执行的权限?/span>
- 一?/span>权限?/span>中的id更改Q那?/span>权限映射?/span>中的记录也就更改了?/span>
- 一个管理组可以执行的权限势必将出错Q这是非怸希望的?/span>
考虑C面的情况Q所以应该?/span>action字段相关联,因ؓQ?/span>
- ?/span>权限?/span>中,id可能发生变化Q?/span>action字段却是在Q何情况下也不可能发生变化的?/span>
- 权限映射?/span>中记录的action字段也就不会变?/span>
- 一个管理组可以执行的权限就不会出错了?/span>
?/span>人员映射?/span>如下图:
我们来了解一?/span>人员映射?/span>?/span>理l表以及人员?/span>之间的字D关联,如下图:
看图中的U圈部分Q先?/span>groupid字段兌Q这U关联方式在数据库中的表现如下图Q?/span>
如图Q?/span>“理?/span>”l的groupid?/span>1Q我们再?/span>人员映射?/span>Q?/span>admin属于理员组Q?/span>administrator属于理员组Q同时也属于理员组?/span>
使用q种兌方式Q是Z查到一个管理组中的人员有谁。和上面一P人员的详l信息是?/span>id字段Q?/span>人员映射?/span>中是masterid字段Q关联查询到的?/span>
id字段Q?/span>人员映射?/span>中是masterid字段Q关联表现在数据库中的Ş式如下图Q?/span>
一个h员可能同时属于多?/span>“理l?/span>”Q如图中Q?/span>administrator同时属于两?/span>“理l?/span>”。所以,?/span>人员映射?/span>中关?/span>administrator的记录就会是两条?/span>
q种兌方式才查询到理l中人员的详l信息有哪些。综合v来,才可以知道一个管理组中的人员有谁Q以及这个h员的详细信息?/span>
再结合上面谈到的权限?/span>?/span>权限映射?/span>Q就实现了需求中?/span>“l?/span>”操作Q如下图Q?/span>
其实Q?/span>理l表中仅仅记录着l的基本信息Q如名称Q组id{等。至于一个组中h员的详细信息Q以及该l能够执行的权限的详l信息,都记录在人员?/span>?/span>权限?/span>中。两?/span>映射?/span>才真正记录着一个组有哪些h员,能够执行哪些权限。通过两张映射表的衔接Q三张实体表之间的交互才得以实现Q?/span>从而完成了需求中提到?/span>“l?/span>”操作?/span>
我们再来看一?/span>权限分栏?/span>?/span>权限?/span>之间的交互。这两张表之间的字段兌如下图:
两张表用了actioncolumnid字段相关联,q种兌方式在数据库中的表现如下图:
如图所C,通过q种兌方式Q我们可以非常清晰的看到权限?/span>中的权限属于哪个分栏?/span>
现在Q数据库l构已经很清CQ分配权限的功能以及“l?/span>”操作都已l实现。下面我们再来分析一下需求中提到的关于权限管理系l的重用性问题?/span>
Z么用这U数据库设计方式搭徏h的系l可以重用呢Q?/span>
- 三张实体表中记录着pȝ中的三个军_性元素?/span>“权限”Q?/span>“l?/span>”?/span>“?/span>”。而这三种元素可以LdQ彼此之间不受媄响。无论是那种cd的业务系l,q三个决定性元素是不会变的Q也意味着l构上不会变Q而变的仅仅是数据?/span>
- 两张映射表中记录着三个元素之间的关pR?/span>但这些关pd全是Zؓ创徏的,需要变化的时候,只是Ҏ据库中的记录q行操作Q无需改动l构?/span>
- 权限分栏表中记录着pȝ使用时显C的分栏。无论是要添加分栏,修改分栏q是减少分栏Q也只不q是操作记录而已?/span>
lg所qͼq样设计数据库,pȝ是完全可以重用的Qƈ且经受得?/span>“变更”考验的?/span>
ȝQ?/span>
此套pȝ的重点在于,三张实体?/span>牢牢地抓住了pȝ的核心成分,而两张映表完美地映出三张实体表之间的交互。其隄在于Q理解映表的工作,它记录着关系Qƈ且实C“l?/span>”操作的概c而系lM的设计是本着可以在不同的MISpȝ?/span>“重用”来满不同系l的功能权限讄?/span>
附录Q?/span>
权限理pȝ数据表的字段设计
下面我们来看看权限管理系l的数据库表设计Q共分ؓ六张表,如下图:
action表:
action表中记录着pȝ中所有的动作Q以及动作相xq?/span>
actioncolumn表:
actioncolumn表中记录着动作的分栏,pȝq行Ӟ左侧菜单栏提供了几块不同的功能,每一块就是一个分栏,每添加一个分栏,该表中的记录׃增加一?/span>,相对应的Q左侧菜单栏中也会新增机一个栏?/span>
actiongroup表:
actiongroup表记录着动作所在的l?/span>
groupmanager表:
groupmanager表记录着理l的相关信息Q每d一个管理组Q这里的记录׃增加一条?/span>
mastergroup表:
mastergroup表记录着理员所在的理l,׃一名管理员可能同同时属于多个组Q所以该表中关于某一名管理员的记录可能有多条?/span>
master表:
master表记录着所有管理员的信息,每添加一个管理员Q该表就会增加一条记录?/span>
2.观点很好
http://www.cnblogs.com/leoxie2011/archive/2011/05/19/2050626.html
一Q前a
权限理pȝ的应用者应该有三种不同性质上的使用Q?/p>
A,使用权限
B,分配权限
C,授权权限
本文只从《用权限》和《分配权限》这两种应用层面分析Q暂时不考虑《授权权限》这U?/p>
二,初步分析
用户和角?nbsp;
说到权限理Q首先应该想刎ͼ当然要设计一个用戯Q一个权限表。这样就军_了一个h有什么样的权限?/span>
做着做着׃发现q样设计太过J琐Q如果公叔R面所有员工都有这L权限呢,每一个h都要配置Q那是一件很痛苦的事情。因此再d一个角色表Q把某些人归Zc,然后再把权限分配l角艌Ӏ角色属下的用户也就拥有了权限?/span>
用户、角色之间的关系?/font>一个用户可以对应多个角Ԍ一个角色可以对应多个用戗多对多关系?/span>
所以需要一个中间表Q相信大安很熟悉,自然不会有疑问?/p>
应用场景
有了用户和角色以后,需要设计应用场景,比如一个应用程序有几大模块Q系l模块、项目管理模块、销售模块)Q?/p>
cMq样的模块就是一U应用场景,常见的还?菜单 ?操作 {等?/p>
假设现在我们设计好了Q应用场景包?模块、菜单、和操作Q那么应该有以下六种关系
- 一个用户可以对应多个模块,一个模块可以对应多个用戗多对多关系?/span>
- 一个用户可以对应多个菜单,一个菜单可以对应多个用戗多对多关系?/span>
- 一个用户可以对应多个操作,一个操作可以对应多个用戗多对多关系?/span>
- 一个角色可以对应多个模块,一个模块可以对应多个角艌Ӏ多对多关系?nbsp;
- 一个角色可以对应多个菜单,一个菜单可以对应多个角艌Ӏ多对多关系?
- 一个角色可以对应多个操作,一个操作可以对应多个角艌Ӏ多对多关系?/span>
于是建立六张表来l护q六U关pR?/p>
q样设计看v来没什么问题。是的,如果没有加入新的关系的话Q这h已经可以满大部分的需求了。可是如果就是如果,新的关系Q需求)往往会加入到pȝq来。这个时候就需要再建立一个新的表。系l的复杂度也随着增加?/p>
可以看出Q这L设计有几个问题:
- 数据表设计太复杂
- 应对pȝҎq于固定
三,把问题简单化
不同的应用场合,你可能会惛_不同的需求,提了一个新的需求以后,可能会发现原来的设计没方法实CQ于是还要添加一个新的表。这也是上面所提到的问题?/span>
其实不必惛_那么复杂Q权限可以简单描qCؓQ?/span>
某某M ?某某领域 ?某某权限
1Q主?/span>可以是用P可以是角Ԍ也可以是一个部?/span>
2Q?nbsp;领域可以是一个模块,可以是一个页面,也可以是面上的按钮
3Q?nbsp;权限可以?#8220;可见”Q可以是“只读”Q也可以?#8220;可用”(如按钮可以点?/span>)
其实是Who、What、How的问?/p>
因此上面所提到的六张表其实可以设计一张表Q?/span>

四,实例说明
下面用一个例子做设计说明?#8220;用户、角色在面上的是用权?#8221;
详细设计Q?/span>
1Q把菜单的配|放在数据库上,每一个菜单对于一个唯一的编?/span>MenuNoQ每一?#8220;叶节?#8221;的菜单项对于一个页?url)?/span>
2Q把按钮的配|放在数据库?/span>Qƈ归属于一个菜单项上(其实是挂在某一个页面上Q。应该一个页面可能会有几个按钮组Q比如说有两个列表,q两个列表都需要有“增加、修攏V删?#8221;。所以需要增加一?/span>按钮分组?span style="font-family: 宋体">字段来区分?/span>
3,把菜单权限分配给用户/角色QPrivilegeMaster?User"?Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess?#8220;Menu",PrivilegeAccessValue为MenuNo,PrivilegeOperation?enabled"
4,把按钮权限分配给用户/角色QPrivilegeMaster?User"?Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess?#8220;Button",PrivilegeAccessValue为BtnID,PrivilegeOperation?enabled"
5,如果需要禁止单个用L权限QPrivilegeOperation 讄?disabled"?/p>
如果不清楚的可以看下图:
数据库设计:
四,l语
说了q么多,其实我推荐的只是Privilege的表设计。这个表是who、what、how问题原型的设计。不仅扩展性、灵zL都很好Q而且复杂的权限理pȝ羃成一句话?/p>
而PrivilegeOperation不仅仅只是用和止两种Q包括分配权限、授权权限,都可以用q个字段定义。只是这无疑加大了应用程序的设计隑ֺQ但是对于表设计可以不做ZQ何的修改可以完成,可以看出其灵zL?nbsp;

]]>