果然不出大家所料，我又没能按时写完文章。时至今日我已经没有什么愧疚的感觉了，这大概就是成长吧。不过话又说回来了，曾经我也是一个月写 10 篇的男人啊。

这篇文章的主要内容是实现按照用户角色动态加载后台管理页面的菜单，有如下几个重点：

• 如何设计数据库以建立用户-角色-菜单之间的联系
• 如何查询与处理树结构的数据
• Vue 如何实现动态加载路由

在正文之前，给大家讲讲这两周背后的故事：

实现动态加载菜单功能的第一步，是完成根据当前用户查询出可访问菜单信息的接口。

基于之前讲过的 RBAC 原则，我们应该设计一张角色表，用角色去对应菜单。同时，为了建立用户与角色、角色与菜单之间的关系，又需要两张中间表。加上之前的用户表，一共需要五张表，各表字段如下图所示：

这里我为后台管理专属的表加上了 admin 前缀。起名是一件十分重要的事情，好的名字是保证代码质量的前提，你们不要学我起的这么随意，很多公司都有自己的起名原则，可以学习一下。（推荐 《阿里巴巴 Java 开发手册》）

另外不同于之前 book 和 category 的做法，这里没有用到外键。一般决定用不用外键需要看系统对数据一致性和效率的要求哪个更突出，但是我觉得数据一致性问题都可以通过代码解决，用外键又麻烦又别扭。

这里我简单介绍下 admin_menu 表的各个字段：

表中的数据你可以自己设计，为了方便测试，记得多注册一个账号以配置不同的角色，并为角色配置相应的菜单。嫌麻烦的话就直接执行我的 sql 文件：

因为我们使用了 JPA 做 ORM，创建 POJO 时需要注意以下几点：

P.S.其实过去我们创建的 POJO 应该再具体一点，称之为 PO（persistant object，持久对象）

• windows 下默认不区分 mysql 字段大小写，而 linux 区分，所以数据库字段不推荐大小写混用（最好都小写），而 Java 属性一般采用小驼峰法命名，JPA 会自动将小驼峰命名转换为下划线命名，比如 nameZh 自动转换为 name_zh
• 数据库中不存在对应字段的属性，需要用 @Transient 注记标注出来

我们需要创建 AdminUserRole、AdminRole、AdminRoleMenu、AdminMenu 四个 PO，比较特殊的是 AdminMenu，这里我贴出来代码：

package com.gm.wj.pojo;

import com.fasterxml.jackson.annotation.JsonIgnoreProperties;

import javax.persistence.*;
import java.util.List;

@Entity
@Table(name = "admin_menu")
@JsonIgnoreProperties({"handler", "hibernateLazyInitializer"})
public class AdminMenu {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    int id;
    String path;
    String name;
    String nameZh;
    String iconCls;
    String component;
    int parentId;
    @Transient
    List<AdminMenu> children;

// getter and setter...

与数据库中不同的是这个 Children 属性，用于存储子节点。

根据用户查询出对应菜单的步骤是：

• 利用 shiro 获取当前登录用户的 id
• 根据用户 id 查询出该用户对应所有角色的 id
• 根据这些角色的 id，查询出所有可访问的菜单项
• 根据 parentId 把子菜单放进父菜单对象中，整理返回有正确层级关系的菜单数据

为了实现这个接口，我们需要新增AdminUserRoleDAO、AdminRoleMenuDAO、 AdminMenuDAO 三个数据库访问对象并编写 Service 对象，也可以顺道把 AdminRole 一套给写了，不过现在还用不上。

在 AdminMenuService中需要实现一个根据当前用户查询出所有菜单项的方法：

    public List<AdminMenu> getMenusByCurrentUser() {
        String username = SecurityUtils.getSubject().getPrincipal().toString();
        User user = userService.findByUserName(username);
        List<AdminUserRole> userRoleList = adminUserRoleService.listAllByUid(user.getId());
        List<AdminMenu> menus = new ArrayList<>();
        for (AdminUserRole userRole : userRoleList) {
            List<AdminRoleMenu> roleMenuList = adminRoleMenuService.findAllByRid(userRole.getRid());
            for (AdminRoleMenu roleMenu : roleMenuList) {
                menus.add(adminMenuDAO.findById(roleMenu.getMid()));
            }
        }
        return menus;
    }
}

这个方法对应上面的前三步。接下来需要把查询出来的菜单数据列表整合成具有层级关系的菜单树。

这里我多说一嘴，由于导航菜单一般不会特别长，所以我们采用这种一次性取出的方式。上述过程中我们会在遍历列表的同时查询数据库，这样的多次交互在前台需要尽量避免，应该先一次性查询出全量数据再作处理以减轻服务器负担。但后台一般是给管理人员使用的，没有那么大的流量，所以不用担心。

如果数据量特别大，那就应该考虑按节点动态加载。即通过监听节点的展开事件向后端发送节点 id 作为参数，查询出所有的子节点，并在前端动态渲染。这种方式的实现等以后用到了再具体讲。

整合查询出的菜单数据的思路如下：

• 遍历菜单项，根据每一项的 id 查询该项出所有的子项，并放进 children 属性
• 剔除掉所有子项，只保留第一层的父项。比如 c 是 b 的子项，b 是 a 的子项，我们最后只要保留 a 就行，因为 a 包含了 b 和 c

整合方法如下：

for (AdminMenu menu : menus) {
    menu.setChildren(adminMenuService.getAllByParentId(menu.getId()));
}

Iterator<AdminMenu> iterator = menus.iterator();
while (iterator.hasNext()) {
    AdminMenu menu = iterator.next();
    if (menu.getParentId() != 0) {
        iterator.remove();
    }
}
return menus;

先说明一下，查询树结构的方法有很多，我见过有按层级查询的，也有直接根据实际情况写死了的。我使用的这种方式好处就是无论几层都能正确地查询出来，虽然执行效率会低一些，但反正是后台用的，问题不大。

有的同学可能对这个方法有疑问，似乎遍历一次应该只有两个层级才对。这里就要考虑一下 Java 的机制了，在 Java 里对象都是引用类型，假设我们把 b 放进了 a 的 children 里，又把 c 放进了 b 的 children 里，那么 c 就被放进了 a 的 children 的 children 里。

而下面的 remove 方法，实际上是把对象名指向了 null，而对象本身仍然存在。所以虽然我们无法再通过 b、c 获取到原来的对象，但 a 里面的信息是不会变的。

为什么删除子项时用 iterator.remove() 而不用 List 的 remove 方法呢？是因为使用 List 遍历时，如果删除了某一个元素，后面的元素会补上来，也就是说后面元素的索引和列表长度都会发生改变。而循环仍然继续，循环的次数仍是最初的列表长度，这样既会漏掉一些元素，又会出现下标溢出，运行时表现就是会报 ConcurrentModificationException。而 iterator.remove() 进行了一些封装，会把当前索引和循环次数减 1，从而避免了这个问题。

整合的过程放在 MenuController 中，整体代码如下：

package com.gm.wj.controller;

import com.gm.wj.pojo.AdminMenu;
import com.gm.wj.service.AdminMenuService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.Iterator;
import java.util.List;

@RestController
public class MenuController {
    @Autowired
    AdminMenuService adminMenuService;

    @GetMapping("/api/menu")
    public List<AdminMenu> menu() {
        List<AdminMenu> menus = adminMenuService.getMenusByCurrentUser();
        for (AdminMenu menu : menus) {
            menu.setChildren(adminMenuService.getAllByParentId(menu.getId()));
        }

        Iterator<AdminMenu> iterator = menus.iterator();
        while (iterator.hasNext()) {
            AdminMenu menu = iterator.next();
            if (menu.getParentId() != 0) {
                iterator.remove();
            }
        }
        return menus;
    }
}

舒服，又贴了这么长代码，篇幅有保障了。

可以测试下 menu 接口，在此之前要确保系统处于登录状态哈，要不可查询不到信息。

前端要做的事情就是处理后端传来的数据，并传递给路由和导航菜单，以实现动态渲染。

我目前大概做了下面几个组件：

主要是实现了页面基础设计，并方便测试动态加载，目前还没有任何功能。效果大概是这个样子：

可以参考 GitHub 上的源码，也可以自己设计一下。开发完组件别忘了添加后台首页的路由哈，别的菜单对应的路由可以动态加载，这个不预先写好就进不去页面了。

之前我们设计 AdminMenu 表，实际上包含了前端路由（router）与导航菜单需要的信息，从后台传来的数据，需要被整理成路由能够识别的格式。导航菜单倒是无所谓，赋给相应的属性就行。

进行格式转换的方法如下：

const formatRoutes = (routes) => {
  let fmtRoutes = []
  routes.forEach(route => {
    if (route.children) {
      route.children = formatRoutes(route.children)
    }

    let fmtRoute = {
      path: route.path,
      component: resolve => {
        require(['./components/admin/' + route.component + '.vue'], resolve)
      },
      name: route.name,
      nameZh: route.nameZh,
      iconCls: route.iconCls,
      children: route.children
    }
    fmtRoutes.push(fmtRoute)
  })
  return fmtRoutes
}

这里传入的参数 routes 代表我们从后端获取的菜单列表。遍历这个列表，首先判断一条菜单项是否含子项，如果含则进行递归处理。

下面的语句就是把路由的属性与菜单项的属性对应起来，其它的都好说，主要是 component 这个属性是一个对象，因此需要根据名称做出解析（即获取对象引用）。同时我们需要把组件导入进来，因此可以利用 Vue 的异步组件加载机制（也叫懒加载），在解析的同时完成导入。

我们数据库中存储的是组件相对 @components/admin 的路径，所以解析时要根据 js 文件的位置加上相应的前缀。

首先我们要思考一下什么时候需要去请求接口并渲染菜单。如果访问每个页面都加载一次，有点太浪费了。如果只在后台主页面渲染时加载一次，那么就不能在子页面中进行刷新操作。因此我们可以继续利用路由全局守卫，在用户已登录且访问以 /admin 开头的路径时请求菜单信息，完整的代码如下

router.beforeEach((to, from, next) => {
    if (store.state.user.username && to.path.startsWith('/admin')) {
      axios.get('/authentication').then(resp => {
        initAdminMenu(router, store)
      })
    }
    if (to.meta.requireAuth) {
      if (store.state.user.username) {
        axios.get('/authentication').then(resp => {
          if (resp) next()
        })
        next()
      } else {
        next({
          path: 'login',
          query: {redirect: to.fullPath}
        })
      }
    } else {
      next()
    }
  }
)

为了保证用户确实登录，仍旧需要向后台发送一个验证请求。

initAdminMenu 用于执行请求，调用格式化方法并向路由表中添加信息，代码如下：

const initAdminMenu = (router, store) => {
  if (store.state.adminMenus.length > 0) {
    return
  }
  axios.get('/menu').then(resp => {
    if (resp && resp.status === 200) {
      var fmtRoutes = formatRoutes(resp.data)
      router.addRoutes(fmtRoutes)
      store.commit('initAdminMenu', fmtRoutes)
    }
  })
}

首先判断一下 store 里有没有菜单数据，如果有说明是正常跳转，无需重新加载。（第一次进入或进行刷新时需要重新加载）

记得在 store.state 里添加变量 adminMenu: []，同时在 mutations 里添加如下方法：

 initAdminMenu (state, menus) {
   state.adminMenus = menus
 }

这个 menus 就是上面的 fmtRoutes。当然也可以把数据放进 localStorage，记得登出时清空就好了。

最后，我们来编写一下菜单组件 AdminMenu.vue：

<template>
  <div>
    <el-menu
      :default-active="'/admin/users'"
      class="el-menu-admin"
      router
      mode="vertical"
      background-color="#545c64"
      text-color="#fff"
      active-text-color="#ffd04b">
      <div style="height: 80px;"></div>
      <template v-for="(item,i) in adminMenus">
        <!--index 没有用但是必需字段且为 string -->
        <el-submenu :key="i" :index="i + ''" style="text-align: left">
          <span slot="title" style="font-size: 17px;">
            <i :class="item.iconCls"></i>
            {{item.nameZh}}
          </span>
          <el-menu-item v-for="child in item.children" :key="child.path" :index="child.path">
            <i :class="child.icon"></i>
            {{ child.nameZh }}
          </el-menu-item>
        </el-submenu>
      </template>
    </el-menu>
  </div>
</template>

<script>
    export default {
      name: 'AdminMenu',
      computed: {
        adminMenus () {
          return this.$store.state.adminMenus
        }
      }
    }
</script>

这里我们利用 element 的导航栏组件，进行两层循环，渲染出我们需要的菜单。<el-submenu> 代表一个有子菜单的菜单项，<el-menu-item> 则代表单独的菜单项。这么命名似乎有点毛病，又似乎没毛病。。。

如果有三个层级，就是 <el-submenu> 套 <el-submenu> 再套 <el-menu-item> ，以此类推。

终于大功告成了。我们来试试用 admin 账户登录，就是上面的效果，菜单是全的：

可以点击用户信息菜单，跳转到相应的路由并加载组件：

使用 editor 账号登录，则只显示内容管理

这个页面做的比较着急，接下来计划按之前的设计完善各个模块，包括：

• 开发用户角色、角色菜单分配组件
• 迁移图书管理功能
• 完成其它模块的基础界面
• 实现功能级权限并开发分配组件

下篇文章的重点是功能级权限的实现，其它方面会顺带提到，但不会说的太细，因为都是讲过的知识点。

总算写完了，但感觉这篇文章还有些地方需要润色一下，大家有看不懂的地方可以尽情提，但像为什么粘了代码跑不起来这种问题我就直接忽略啦。