【Blog.Core开源】框架集成部门权限

（Blog.Core框架功能点概述）

Blog.Core开源四年啦，一行行代码凝结了大家的热情和心血，基本功能骨架已完成，欢迎更多的公司和企业使用哟。真实公司留言盖楼可获得一对一技术指导：

https://github.com/anjoy8/Blog.Core/issues/75

书接上文，上回咱们说到了《【Blog.Core开源】将Program升级为.NET6.0版本》，终于将项目完全的升级到了6.0，而且6.0是一个三年的LTS版本，所以可以暂时稳定一段时间了。正好最近也把框架中最后一个版图——数据部门权限，给集成进来了。当然每个公司的具体情况不一样，我只是提供一个抽象的功能点，还需要各自在具体的情况中，做相应的修改。

PS：所有代码已经全部更新到master分支，欢迎批评指正。

今天简单说一下，部门权限设计的概要设计吧，如果不是很清晰，下次直播的时候，我再详细的讲讲这一块，配合着鉴权认证一起。

1、部门表结构概要设计

我们都知道，部门表结构其实挺简单的，无非就是id、name、pid之类的常规设计，然后就是写业务逻辑，做CURD接口了，其中稍微需要动脑筋考虑的事情就是如何做到级别的划分和快速定位。

我这里先设计了一版，主要还多了一个关系码的字段，用来表示当前部门的上游节点信息，每次更新的时候要同步更新，要注意：

这么设计的好处是方便我们快速的查找整个部门树的关系，比如：

1、可以查询0,1的所有同级部门，用equal即可满足；

2、可以查询0,1的所有子集部门，用contain即可，同时也可以进一步细分是所有子集还是下一级（用长度即可快速找到）；

3、可以快速查询当前部门的部门链（下文就会用到）；

这样部门权限就很清晰明了，因为快速定位部门树关系对我们来说很重要。

剩下的就是CURD了，比较简单，大家看Blog.Core源码就行了，最终展示到页面上的效果是这样的：

（代码下载后，生成种子数据，用超级管理员查看效果）

（部门树型列表展示）

（添加部门，勾选父级部门）

2、给用户绑定部门信息

有了部门信息，那我们就需要绑定到用户上了，一般来说一个用户肯定就是一个部门了，如果一定要实现多个部门，就需要继续抽象一个逻辑模型了，下文会说到。

这块逻辑比较简单，就是在用户表添加一个部门id就行，不用存放整个父级上游关系链，让部门子领域处理就行，用户不需要考虑这块。最终的效果就是这样的：

(用户列表)

（用户添加/编辑部门信息）

我们在把部门id存到数据库里，然后通过部门表的CodeRelationship字段给带出完全的部门名称和部门id数组，是不是很方便，核心代码是这样的：

代码语言：javascript复制

 private (string, List<int>) GetFullDepartmentName(List<Department> departments, int departmentId)
 {
     var departmentModel = departments.FirstOrDefault(d => d.Id == departmentId);
     if (departmentModel == null)
     {
         return ("", new List<int>());
     }

     // 获取整个链路节点
     var pids = departmentModel.CodeRelationship?.TrimEnd(',')
                 .Split(',').Select(d => d.ObjToInt()).ToList();
     pids.Add(departmentModel.Id);
     var pnams = departments.Where(d => pids.Contains(d.Id)).ToList().Select(d => d.Name).ToArray();
     var fullName = string.Join("/", pnams);

     return (fullName, pids);
 }

其实到了这里，用户部门权限已经基本定型了，我们先考虑下以后怎么做划分——我们编辑某条目标数据，比如是绩效信息，每条目标数据都会有个UserId，那当前人登录的时候，就根据UserId，查出来部门DepartmentId，就可以获取整个部门的数据了。这是最简单的最基础的一套部门权限数据，但是我们肯定不会满足于这种情况的。因为我们经常会有这个需求：

1、查询我同级别的所有部门数据；

2、查询我下属的数据；

3、甚至是跨部门查询数据；

那这个时候就需要我们再往上抽离一层，将用户和部门关系进行融合，但是我把这块逻辑给放到Role上了，整体流程是：

根据User查询Role，根据Role查询具体的控制Department的逻辑，从而实现目的。

3、角色和部门逻辑的绑定

这块逻辑是可以放到User表的，但是这样每个人都需要一一的标记，无法做到统一的处理，所以我还是放到了Role上，先看效果吧：