上回说到
需求:机构信息 - 左侧添加组织架构,按系统-父机构-子机构-部门-用户显示
从需求可以看出返回的Json对象必须是具有层级结构的,解决这个需求首先要思考的是返回Json的层级结构及包含关系
提出猜想
因为是层级的包含关系
1、所有父机构所在的系统子机构必在其中
2、同理,子机构包含的部门,父机构必然包含
因为,向上我们只需要找出顶级父辈的所在系统
向下我们只需找出底级子辈所在的部门
这样思路就清晰了,我们只需要递归找出机构表,所有机构的层级结构即可
对应的返回层级:
系统{ 系统信息 顶级父辈机构{ 机构信息 ... 底级子辈机构{ 机构信息 部门{ 员工信息 } 部门{ 员工信息 } ... } } }
验证猜想
使用SQL递归查询数据(这个地方只是验证过程,后面并不需要使用递归SQL,无需担心)
id instid instCode instName parentId
1 1111 0001 白虎队 0
131 2222 0002 灰狼队 1111
132 3333 0003 青龙队 2222
164 4444 0004 赤蛇队 3333
查询机构角色表,找到机构对应的角色Id
instid role_id 1111 root 2222 null 3333 null 4444 null
在这里就可以看出我们的第一个猜想是正确的,因为只有顶级父节点才有角色ID,
也就证明了其他子节点是无法通过角色ID查询到对应的系统信息,即系统信息只有顶级父节点才有
查询角色表,找到对应的系统Name
select sys_name from role where role_id = "root";
查询系统表,找到对应的系统信息
select * from t_ims_auth_sys where sys_name = "炒鸡特工队";
经过验证发现猜想1在数据库中的映射关系正是这样,而猜想2却在数据库中的映射关系和我们猜想的并不同,
这也证明了当有解决问题的想法出现时,一定要查询数据库验证,保证理论正确,才可以得出正确的操作步骤
那让我们来看一下猜想2哪里出错了
select * from t_ims_auth_user where inst_name ="白虎队";
经过查询数据库我们发现,使用机构名称查询用户表时,即使是顶级父辈也有对应的用户信息
(实际上经查询是每级都有用户信息和部门信息的),即用户信息并不仅仅保留在底级子辈机构中
层级结构
OK,但这并不妨碍我们解决问题
上述证明我们设想的层级结构其实是有一点问题的,进行修改后,我们的层级结构终于出现了
(累の不行,真事 注:真事=真的是这样)
系统{ 系统信息 机构{ 机构信息 部门信息{ 员工信息 员工信息 ... } 部门信息{ 员工信息 员工信息 ... } ... 子机构{ ... } } }
细节处理
部门和员工之间的关系可以通过Map进行关系处理
先根据机构名称,查询所有的对应的user
select * from t_ims_auth_user where inst_name ="白虎队";
遍历用户,写入Map,Key为部门名称 Value为user信息
List<User> list = ... Map<String,object> map = ... for(User user:list){ //如部门name无,写入暂无 if(){ } map.put(user.getDeptName,user) }
这样我们整个业务流程就算是捋清了