这节我们来完成菜单的实现。一般菜单是系统里面必不可少的一项,像我们的后台管理系统,一般左边都有功能导航菜单,门户网站,博客,页面顶部也会有导航菜单。大部分菜单,都是可以支持多层级的,理论上我们可以做成无限层级的。这种菜单模型其实是一个树形结构模型,或者父子结构模型,之前我们处理的实体全部都是非树形结构的(其实一般角色是树形结构的,笔者前面未了简化处理,没做成树形结构),一般来说,笔者把实体对象统分为普通对象和树形对象。
1、实现树形结构的方案
总的来说,实现树形结构的方案有四种:
1.1邻接表
邻接表将所有节点数据放在一个表中,然后使用一个属性来标示该节点的父id。这种方案简单,直观。插入,移动,删除效率都比较高,查询效率比较低,需要递归查询(查询一个节点的所有子节点,包括子节点的子节点)。一般在数据量小的时候,我们可以一次查询出所有节点,在内存中再将其组装成树,还可以对整棵树进行缓存。数据量多的时候,我们可以进行异步加载,即每展开一个节点,才去查询他的直接子节点(不需要递归查询)。
1.2路径枚举
为了解决邻接表递归查询的问题,路径枚举在邻接表的设计上,增加了一个路径字段。
如上图所示,paths就是从根节点id到当前节点id的一个层次结构。
该方案在插入,移动的时候效率比较低,需要额外维护一个paths字段,在插入时,paths字段的生成,首先需要获取其父节点的paths值,然后再加上自身节点的id值。在移动时,所有子节点的paths将会跟着发生变化,需要重新计算。在查询任意节点的子节点(包括非直接子节点)时,只需一个sql语句就能查出,如查询A节点所有的子节点,只需要加入paths like '1-%'条件即可。
该方案理论上树形结构可以不限层级,但是由于paths字段的存在,字段长度总是有限的,所以存在太深层的节点paths字段超出预设长度的情况。当然我们也可以设置成大文本字段,如mysql里面的text,即使这样,我们一般建议id是序列增长的,如果像id是uuid这种,即使是大文本字段,paths的值也未免太恐怖了。
1.3左右值编码
1.4闭包表
左右值编码和闭包表的设计,笔者就不讲了,因为笔者并没有对这两种方案做过实际应用,但不不代表这两种方案不行,存在即合理,他们也有自己的使用场景,大家可以自己搜索其相关方案的实现。
2、菜单实体
在这里,我们先采用邻接表的方式实现菜单模块,后面根据情况,看是否需要再处理路径枚举的例子。
我们在com.cangzhitao.springboot.study.security.entities包下新建Menu实体:
其中parent属性,这里使用了ManyToOne,因为一个节点可能有多个子节点,多个子节点可能对应一个父节点,所以对于parent来说,是ManyToOne,对于children来说,是OneToMany,两者维护方式不一样,ManyToOne是采用外键的方式,OneToMany默认是采用中间表的方式,即使用中间表,一个字段记录当前节点id,另一个字段记录当前节点的所有直接子节点id。因为我们决定采用邻接表的方式,所以不会维护节点的子节点。为了避免转json串的时候出现死循环,将parent属性设置serialize=false,即不需要序列化,如果有需要,我们可以序列化一个parentid出来,没必要整个对象。为了方便前端展示树形结构,又需要children属性,这里我们将属性设置成Transient,表示不需要将它进行持久化处理。
我们再添加一个辅助方法,方便添加子节点
3、Repository
Repository和之前的一样
4、Controller
我们将PermController复制一份,改成MenuController,先去掉代码里面的权限验证,将对应的Perm都改成Menu。我们的树形结构最终应该将是这样的效果
所以查询页面和普通对象的表格不一样,是一棵树,不需要分页查询什么的。树的话,一般有立即加载和延迟加载两种,立即加载就是一次请求返回整个树结构,一般适用于节点少的情况,延迟加载则是最开始只加载根节点,点击一个节点,再加载其直接子节点,一般是处理节点数很多的情况。因为我们的菜单不会很多,所以我们这里使用立即加载的模式,需要后台有个服务一次性将树结构返回。
在getTree方法里面,我们先将所有的菜单查出来,然后将其循环放入了一个map里面,然后再次遍历每个节点,如果该节点没有父,或者父已经被删除(这种应该属于意外情况,父节点删除了,子节点要么跟着一起删除,要么将其父节点id进行修改),就将其放入根节点,其余的将放置对应的父节点下面。这里做了两次循环,两次循环的目的是避免在第二次循环时,map中还未有相应的父节点数据,特定情况下,如果能确保循环是有序的,且先第一层根节点,再第二层节点,第三层节点这样,可以只做一次循环。如果需要排序,可以在addChild方法里面做处理。
5、树形结构展示页面
我们从别的地方复制一个列表页面,进行对应修改,查询按钮我们改成刷新按钮,表格组件换成tree组件。
我们暂时先直接在数据库增加几条记录,测试我们的页面:
如果一切正常后,你将可以看到如下界面:
如果页面有问题,请回顾上面的代码,看哪里有遗漏。
6、新增页面
树形结构的新增和之前的新增还有点不同,树形结构的新增,我们需要选择一个父菜单,当然父菜单可以为空。我们先还是复制一个新增页面,进行修改。
我们设计使用http://localhost:8080/security/menu/add?parent=5 来进行参数传递,因为我们并没有启用vue的路由,这里我们添加一个方法,用来获取url中的参数
我们先测试下,是否能正常取到参数。
测试成功后,我们将给查询parent复制给表单
父我们可以设置成readonly,也可以做成可编辑的,因为用户可能在列表界面选错了父,在新增界面我们可以让用户再次重新选择父,但这样页面更加复杂,我们需要再次弹窗,这里我们先按简单的来,做成只读的。
新增页面就做好了,请读者自行测试下新增。
接下来,我们把列表页面和新增串起来。
修改列表页面,暂时把三个按钮都放出来
新增的时候,我们需要判断当前树是否有选中一个节点,选中的节点我们要获取他的id,作为新增页面的参数。
这样整个流程就串起来了。
7、编辑页面
复制一份编辑页面
测试发现页面报错
这是由于我们把parent属性设置了不序列化,导致get查询的时候,返回到前端没有了parent属性。这里有很多个方案,我们取消parent的不序列化设置,然后修改之前的getTree方法,手动将parent属性都设置成null。还一个是我们将parent序列化成parentid,然后前端根据parentid再进行一次查询。如果parent不允许编辑,我们也可以不传parent,或者只传个parent.name用于显示,具体到不同的业务场景,大家可以自由选择,这里我们还是采取第一种方案吧。
再次测试,页面正常了,但编辑不生效,原来我们后台的编辑方法的赋值操作还没完成
测试ok后,我们将列表页面和编辑页面串起来。之前表格编辑,我们的编辑删除按钮,都跟数据是在一行的,在tree组件里面,我们也可以这么做,如下图所示:
这里为了简单处理,我们将编辑和删除按钮,放到新增按钮一起。
8、删除功能
上面说了,我们删除节点的时候,要一并删除子节点,我们修改后台的删除方法,做一个递归删除
可以看到,之类递归删除,确实会比较慢,会执行多次sql,这是效率最低的一种方法,一般来说,可以优化成只执行一个查询sql,一个删除sql的。
9、权限
权限请大家自行完善
10、总结
这节介绍了树形结构常见的实现方案,因为篇幅有限,写了一个最简单的实现,只适用于数据量少的情形,大家可以自己尝试下路径枚举的实现。
代码:
https://github.com/www15119258/springboot-study/tree/branch25