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

作者：李玉宝（李玉宝的代码人生）