DDDLite的权限管理

领域驱动设计实战—基于DDDLite的权限管理

在园子里面,搜索一下“权限管理”至少能得到上千条的有效记录。记得刚开始工作的时候,写个通用的权限系统一直是自己的一个梦想。中间因为工作忙(其实就是懒!)等原因,被无限期搁置了。最近想想,自己写东西时,很多都是偏理论方面的,常常找不到合适的例子来论证自己的观点。于是用业余时间来写点东西。

园子中的权限管理系统有以下几种:

  1. 写的好的,界面NB的,但不开源,毕竟人家辛辛苦苦的劳动成果;
  2. 写的好的,也公开源码,但不公开数据库设计和一些流程设计,你得看着源码去猜字段去猜流程;
  3. 不定期讲源码和放截图的,丫的就是不放出项目的,这种同1,就是没事换个马甲来水点广告;
  4. 入门级的,开放源码的,但那源码实在是不想多看两眼;

什么也不说了,开干!文字太多了,来个动态图缓一缓:

需求

首先,做个东西必须要把需求搞清楚。园子里面的权限管理需求分析的比较合理的,应该是萧秦的我的权限系统设计实现MVC4 + WebAPI + EasyUI + Knockout(一) ,具体总结如下:

1、权限资源
    a.菜单权限  经理和业务员登陆系统拥有的功能菜单是不一样的 
    b.按钮权限  经理能够审批,而业务员不可以 
    c.数据权限  A业务员看不到B业务员的单据 
    d.字段权限  某些人查询客户信息时看不到客户的手机号或其它字段

2、用户,应用系统的具体操作者,我这里设计用户是不能直接分配权限的,必须要分配一个角色,角色中再分配权限,如果某个用户权限比较特殊,可以为他专门建一个角色来应用解决,因为如果用户也可以分配权限系统就会复杂很多。【我采用的还是可以直接给用户分配菜单/按钮,毕竟我们的人员就喜欢搞些特殊待遇】

3、角色,为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,以上所有的权限资源都可以分配给角色,角色和用户N:N的关系。

4、机构,树形的公司部门结构,国内公司用的比较多,它实际上就是一个用户组,机构和用户设计成N:N的关系,也就是说有时候一个用户可以从属于两个部门,这种情况在我们客户需求中的确都出现过。

设计

本来想用DDD(也就是把CQRS/AES等一堆的东西全用上,如果你想学习完整的DDD框架,可以参考我的另一个项目BestQ&A --开源中国推荐项目/集CQRS AES等DDD高级特性于一体的问答系统)实现这个项目,思考再三还是被自己否定了。毕竟自己也在学习真正的领域驱动设计,思想上不是很成熟。再者,我相信对于普通的经典DDD架构(好高大上的说,悄悄地告诉你其实就是分层分的格调不一样!),我是有绝对的信心可以把控的。

与其他权限管理相同的地方

使用了万恶的EF+MVC结构,当然,我没恶俗到用EasyUI,为了体现个性,选择了酷炫的基于bootstrap的B-JUI前端(炫不炫,你说了算)。相同的东西总是无趣,你可以无视,请把注意力放在下面。

与其他权限管理不同的地方

1、项目采用经典DDD架构(用沃恩.弗农大神的话,其实这是DDD-Lite)思想进行开发,简洁而不简单,实用至上,并且所写每一行代码都经过深思熟虑,采用Autofac对项目进行解耦,符合S.O.L.I.D规则!来秀一下内在美:

  1. using OpenAuth.Domain;
  2. using OpenAuth.Domain.Interface;
  3. using System;
  4. using System.Collections.Generic;
  5. using System.Linq;
  6. namespace OpenAuth.App
  7. {
  8. public class OrgManagerApp
  9. {
  10. private IOrgRepository _repository;
  11. public OrgManagerApp(IOrgRepository repository)
  12. {
  13. _repository = repository;
  14. }
  15. public IList<Org> GetAll()
  16. {
  17. return _repository.LoadOrgs().ToList();
  18. }
  19. /// <summary>
  20. /// 部门的直接子部门
  21. /// <para>TODO:可以根据用户的喜好决定选择LoadAllChildren或LoadDirectChildren</para>
  22. /// </summary>
  23. public IList<Org> LoadDirectChildren(int orgId)
  24. {
  25. return _repository.Find(u => u.ParentId == orgId).ToList();
  26. }
  27. /// <summary>
  28. /// 得到部门的所有子部门
  29. /// <para>如果orgId为0,表示取得所有部门</para>
  30. /// </summary>
  31. public IList<Org> LoadAllChildren(int orgId)
  32. {
  33. string cascadeId = "0.";
  34. if (orgId != 0)
  35. {
  36. var org = _repository.FindSingle(u => u.Id == orgId);
  37. if (org == null)
  38. throw new Exception("未能找到指定对象信息");
  39. cascadeId = org.CascadeId;
  40. }
  41. return _repository.Find(u => u.CascadeId.Contains(cascadeId) && u.Id != orgId).ToList();
  42. }
  43. /// <summary>
  44. /// 添加部门
  45. /// </summary>
  46. public int AddOrUpdate(Org org)
  47. {
  48. if (org.Id == 0)
  49. {
  50. ChangeModuleCascade(org);
  51. _repository.Add(org);
  52. }
  53. else
  54. {
  55. _repository.Update(org);
  56. }
  57. return org.Id;
  58. }
  59. /// <summary>
  60. /// 删除指定ID的部门及其所有子部门
  61. /// </summary>
  62. public void DelOrg(int id)
  63. {
  64. var delOrg = _repository.FindSingle(u => u.Id == id);
  65. if (delOrg == null) return;
  66. _repository.Delete(u => u.CascadeId.Contains(delOrg.CascadeId));
  67. }
  68. #region 私有方法
  69. //修改对象的级联ID,生成类似XXX.XXX.X.XX
  70. private void ChangeModuleCascade(Org org)
  71. {
  72. string cascadeId;
  73. int currentCascadeId = 1;  //当前结点的级联节点最后一位
  74. var sameLevels = _repository.Find(o => o.ParentId == org.ParentId && o.Id != org.Id);
  75. foreach (var obj in sameLevels)
  76. {
  77. int objCascadeId = int.Parse(obj.CascadeId.Split(‘.‘).Last());
  78. if (currentCascadeId <= objCascadeId) currentCascadeId = objCascadeId + 1;
  79. }
  80. if (org.ParentId != 0)
  81. {
  82. var parentOrg = _repository.FindSingle(o => o.Id == org.ParentId);
  83. if (parentOrg != null)
  84. {
  85. cascadeId = parentOrg.CascadeId + "." + currentCascadeId;
  86. org.ParentName = parentOrg.Name;
  87. }
  88. else
  89. {
  90. throw new Exception("未能找到该组织的父节点信息");
  91. }
  92. }
  93. else
  94. {
  95. cascadeId = "0." + currentCascadeId;
  96. org.ParentName = "根节点";
  97. }
  98. org.CascadeId = cascadeId;
  99. }
  100. #endregion 私有方法
  101. }
  102. }

2、教科书级的分层思想,哪怕苛刻的你阅读的是大神级经典大作(如:《企业应用架构模式》《重构与模式》《ASP.NET设计模式》等),你也可以参考本项目。不信?有图为证,Resharper自动生成的项目引用关系,毫无PS痕迹!

记得以前弦子哥写过一篇园子里面搭构架对比的文章(.Net项目分层与文件夹结构大全(最佳架子奖,吐槽奖,阴沟翻船奖揭晓)),本想也建他10几个项目,想一想还是算了,折腾读的人也折腾我自己。毕竟我的项目还没有分布式的需求,就算有,也得遵循分布式设计的最高准则------能不用分布式就不要用!

所以精简到6个项目,个个都是精华!

所有项目都依赖于领域层,而领域层不关心任何数据库实现或界面UI实现;

通过依赖注入真正实现了上层与数据库分离,虽然数据库访问采用了EF的方式,但WEB层对此毫不知情!

3、经过N次优化的数据库结构设计。本来数据库核心表中有很多多对多的关系(用户与机构/用户与角色/角色与模块等等),如下:

代码写到一半的时候,觉得何苦呢,为什么以前设计权限的人都喜欢这么设计?去你的,看我的:

瞬间少了很多,代码风格也可以统一起来,多美好的事情啊。你会问:所有多对多关系放在一张表,性能怎么办?什么?性能?没有千万级数据,别和我提性能。如果你的系统几十万数据时都会很卡,还是去恶补一下数据库基础吧!

界面

人要脸树要皮,没图没真相!

源码及说明

项目地址:https://git.oschina.net/yubaolee/OpenAuth.Net

源码中包含所有的程序代码,数据库PowerDesigner设计图,CodeSmith生成模板,数据库初始脚本。请下载源码后,先用Nuget还原引用的第三方包,再修改一下web.config里面的连接字符串。

当前代码已经实现核心功能如下:

  • 模块/用户/部门/角色的分级管理;
  • 为用户分配角色或直接为用户分配模块;
  • 根据模块URL地址与MVC的Controller适配授权;
  • 页面菜单按钮分配;
  • 内部已经集成log4net,只需要简单的 LogHelper.Log("日志内容") 即可;

最近开发功能展望:

  • 菜单授权处理;
  • 数据权限处理;
  • 用户分级授权功能;

短短一文怎么能表达完一个项目的功能与思想!在后续的博客中,我会结合自己对企业开发的一些看法,对DDD的一些看法,对重构的一些看法,等等等等,来讲述自己的程序人生。

本博客其他精彩内容:http://www.cnblogs.com/yubaolee/p/Catalogue.html

时间: 2024-10-23 09:09:15

DDDLite的权限管理的相关文章

基于DDDLite的权限管理OpenAuth.net 1.0版正式发布

距离上一篇OpenAuth.net的文章已经有5个多月了,在这段时间里项目得到了很多朋友的认可,开源中国上面的Star数接近300,于是坚定了我做下去的信心.最近稍微清闲点,正式推出1.0版,并在阿里云上部署了一个在线演示(文章结尾处给出在线演示链接).相比刚开始时的版本,现在整个架构已经稳定,系统功能性,代码可读性维护性都有质的飞跃. 本文主要介绍系统结构及未来一段时间的开发计划. 项目简介 本项目采用经典DDD架构(用沃恩.弗农大神的话,其实这是DDD-Lite)思想进行开发的一套符合国情的

OpenAuth.net:.net 领域神级权限管理 2.0 将发布

OpenAuth.net 项目即将迎来年度最大一次更新.强力引入Workflow工作流引擎!尽情期待. 有图有真相: 该项目采用经典DDD架构(用沃恩.弗农大神的话,其实这是DDD-Lite)思想进行开发的一套符合国情的基于用户和角色的RBAC系统,系统的产生原因及与众不同的地方可以参考:领域驱动设计实战—基于DDDLite的权限管理OpenAuth.net,这里就不过多介绍. 更多OpenAuth.net介绍qkxue.net

尝试封装适用于权限管理的通用API

谈谈我对权限系统的简单理解 最近一段时间在研究权限系统,在园子里看到个很牛逼的开源的基于DDD-Lite的权限管理系统,并有幸加入了作者的QQ群,呵呵,受到了很大的影响.对于权限管理我有我自己的一些简单想法,说简单也许是因为我对权限管理领域的理解有限,我所做的仅是基于我本人对权限管理的理解.以最终目的为出发点,应该就是一个系统根据不同的登陆用户的不同权限而呈现不同的界面,不同的操作,数据和资源等等.从实现方面大体可以分几个部分:用户登陆管理部分,用户权限分配部分,响应终端或界面部分.目前我已经根

Oracle 表空间和用户权限管理

一. 表空间 Oracle数据库包含逻辑结构和物理结构. 数据库的物理结构指的是构成数据库的一组操作系统文件. 数据库的逻辑结构是指描述数据组织方式的一组逻辑概念以及它们之间的关系. 表空间是数据库逻辑结构的一个重要组件. 表空间可以存放各种应用对象,如表.索引等. 而每一个表空间由一个或多个数据文件组成. 1. 表空间的分类 表空间可分为3类: 永久性表空间:一般保存表.上天.过程和索引等数据.system.sysaux.users.example表空间是默认安装的. 临时性表空间:只用于保存

linux文件权限管理与ACL访问控制列表

一.文件属性 1.文件属性: 文件属性操作 chown : change owner  ,设置文件所有者 chgrp : change group  ,设置文件的属组 文件属主修改: chown 格式:chown [OPTION]- [OWNER][:[GROUP]] FILE- 用法: OWNER OWNER:GROUPNAME    (同时修改属主.属组) :GROUPNAME                (默认属主,修改属组) ( 命令中的冒号可用.替换:) chown  –refere

mysql的权限管理

mysql的权限管理1.授权的基本原则   只授予满足要求的最小权限,但要注意使用户能够授权给别的用户(with grant option)   对用户设置登录的主机限制   删除没有密码的用户   满足密码的复杂度,设置较为复杂的密码   定期检查用户的权限,适当收回不需要的权限   2.给用户授权  mysql> grant all on *.* to 'root'@'10.0.5.150' identified by 'aixocm';  mysql> flush privileges;

Oracle权限管理详解

转载--CzmMiao的博客生活 Oracle 权限 权限允许用户访问属于其它用户的对象或执行程序,ORACLE系统提供三种权限:Object 对象级.System 系统级.Role 角色级.这些权限可以授予给用户.特殊用户public或角色,如果授予一个权限给特殊用户"Public"(用户public是oracle预定义的,每个用户享有这个用户享有的权限),那么就意味作将该权限授予了该数据库的所有用户.对管理权限而言,角色是一个工具,权限能够被授予给一个角色,角色也能被授予给另一个角

浅析Linux系统下用户与权限管理

Linux作为一种多用户多任务操作系统,在日常的使用中不可避免地要划分出一个角色的概念来管理和使用计算机,这个角色与每一个计算机使用者关联,在Linux中称这种角色为用户.而在每一个用户使用计算机的过程中,又必然存在对有限计算机资源使用的限制性,那么操作系统就必须提供一种途径来保证每个用户独立.合理的使用计算机. 一.用户和用户组管理   (一)用户及用户组相关基本概念  用户:泛指计算机的使用者.用计算机可识别的用户ID(UID,user id)标识. 用户组:用户容器,用来将多个用户合并为一

centos用户权限管理

进程是以其发起者的身份运行的,它对文件的访问权限,取决于此进程的用户的权限.在linux操作系统启动的过程中,为了能够让后台进程或服务类进程以非管理员的身份运行,通常需要为此创建多个普通用户,而这类用户从不需要登录系统,仅让其他进程以他的身份运行,从而仅能获取普通权限的用户.为此这部分用户称系统用户.同时用户与组密不可分.进程的运行是以它的属主(又称,发起者)来访问的.它能访问资源的权限取决于发起者对某个资源的访问权限.下面是从用户和授权两个角度来讲解用户授权管理. 用户管理 用户按类别分管理员