这节我们来完成菜单的实现。一般菜单是系统里面必不可少的一项，像我们的后台管理系统，一般左边都有功能导航菜单，门户网站，博客，页面顶部也会有导航菜单。大部分菜单，都是可以支持多层级的，理论上我们可以做成无限层级的。这种菜单模型其实是一个树形结构模型，或者父子结构模型，之前我们处理的实体全部都是非树形结构的（其实一般角色是树形结构的，笔者前面未了简化处理，没做成树形结构），一般来说，笔者把实体对象统分为普通对象和树形对象。
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