近期在一个新项目中设计方案的一个用户管理权限的设计方案,很愿意与大伙儿一起探讨及共享.
设计理念
我的设计理念也就是说是我要完成的作用
1.用户的管理权限根据角色来操纵,一个用户能够有着好几个角色.
2.用户有着不一样角色时,其管理权限应该是好几个角色互相的补集.
3.一个角色有着好几个模块
4.用户的前台接待莱单显示信息依据角色所有着的模块所决策,不一样的用户在前端开发显示信息的实际操作莱单是不一样的。
5.网页页面中的作用按键依据模块中所包括的作用所界定,根据模块及角色所有着的管理权限开展操纵
6.可以看某一模块有什么用户,什么相匹配角色,并对其开展独特权限管理.
7.能够对于单独用户开展独特设定
我还在我的Project中,大部分做到了之上的实际效果及作用,但在具体全过程中发觉一些存在的不足。由于全部权限设计是根据数据库查询设计制作中,因此数据信息的载入当信息量大时(我常说的信息量是以万之上来计)很有可能对特性有一定的危害。但针对一般来说,好几千用户这类的我觉得還是能够承担的。我能在后面表明存在的不足。
概念模型设计
基础设计方案:
1.最先,设计方案数据库查询.
数据库查询的设计方案其实我可能大家都很了解了
基础表:用户表,角色表,模块表,功能表,管理人员表.假如牵涉到公司性质的,很有可能会依据必须再加上组织架构表,群聊表等其他輔助表
用户

用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第1张

 

管理人员

用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第2张

角色

用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第3张

模块

(我的模块表考虑到了子模块的要素,因此会有深度,父模块ID这两个字段名,在之后开发设计过中,因为构思的变化,IsRootModule,FunctionCode我还沒有采用,为了更好地让全部管理权限系统软件通越来越更通用性,我还将其独立设计方案变成另一个表)

用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第4张

功能表(功能表便是模块相匹配的作用:提升,删掉,改动,详尽,目录,访问 ,导出来,导进这类的)
用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第5张

业务流程表:用户-角色表 模块-功能表 角色-模块表

要完成一个用户好几个角色(1 to n),一个角色好几个模块(1 to n),一个模块好几个作用(1 to n),那么就得再加上好多个有关的业务流程表,以前考虑到用主视图去完成,我本人之见,主视图最好是只用于获取数据,不必用于开展数据信息实际操作.之后证实是不可取的,这儿要留意的便是在具体的业务流程实际操作中,应当尽量减少反复的数据整理. 这种表都非常简单,但却很重要

用户-角色:
用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第6张

角色-模块:

用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第7张

模块-作用:

用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第8张

大伙儿能够见到,表结构非常简单,字段名也非常少,设计方案也类似。全是将关联的字段名ID取下来做数据存储。

主视图:用户-角色-模块-作用主视图
用户权限管理设计[图文说明] 设计 用户权限 相关技巧  第9张

 

很有可能大伙儿会感觉很怪异,为何这儿出現member_role呢。由于我们在数据分析表中只存储了ID值,而相匹配的RoleName字段名并沒有包括在其中,这儿的主视图便是获得关系表格中别的所必须的字段名数据信息了。此外2个主视图各位看姓名应当就了解他的用途了。

存储过程:分别表的提升,删掉,改动,及目录数据信息. 分辨是不是存有同样的数据信息
(CUDLIS-Create, Update,Delete,IfExist,Show,List)

存储过程我不一一列举了,非常简单的,你要是写成下边这种大部分你一直在开发设计全过程就不容易有过多难题了. 留意的是:在互相关系的业务流程表格中,最好是能对数据信息插进开展反复数据信息分辨(用户角色表,模块功能表,角色模块表,尽量减少反复的数据信息插进)我将大概必须完成的业务流程列个表给大伙儿参照:

用户表:(Insert ,Update ,IfExist ,Show, Delete)

用户角色表:(Insert ,Update,IfExist,Delete,RoleListByUserID,UserListByRoleID)

角色表:(Insert,Update,IfExist,Show,Delete)

角色模块表:(Insert,IfExist,Delete,Show,RoleListByModuleID,ModulistByRoleID)

模块表:(Insert,Update,IfExist,Show,Dlete,ListByRootModuleID,ListByModuleLevel)

模块功能表:(Insert,Update,Delete,FunctionListByModuleID)

对于用户立即获得其全部的管理权限时,应当有一个独立的Procedure从主视图中Member_Role_Module_Function中获得其相匹配的数据信息,那样就可以获得要想的物品了。

概念模型设计一部分应当就是这样差不多了。我觉得这应该是通用性的。在具体应用全过程中,我本人觉得应当有一些改善点:

1.模块与作用一部分,可以用字符串数组的方式将模块相匹配的作用存有一个数据字段中,那样很有可能在你的编码撰写中能够省下较多的時间并产生大量的便捷(主要是可以用split()来替代经常的数据获取业务流程)这一我还在最开始设计方案中沒有想起这一点,有点儿失策.

2.对于N级模块的管理权限呈现难题,怎么让父模块承继子模块的管理权限这个是也没有充分考虑的,但是我觉得应当可以用IsRootModule这一字段名来作文章内容,遗憾我都想不到如何去整这一字段名。当子模块许多 时,在前端开发UI展现的情况下是不是会出現比较慢的状况?这一也没有去做检测。含有一定的风险性
但在前端开发UI展现我都想不到或完成好的方法,我可以想起的应该是像GridViewTree那类非常好。

这一权限设计早已在我的Project中应用,暂时没有发现什么难题,并且为我之后对其他信息系统集成也很有协助。对于怎样在C#中完成业务流程,本人觉得要是了解数据库查询怎样整的,那C#中的业务流程完成仅仅一个取数操作流程。续篇与大伙儿再相互共享探讨.