最近，公司老大给了这个任务，功能差不多完成了，现将一些经过分享给大家！
------------------开始设计时-----------------
- 菜单权限的设计
思路：
- 5个表的建立：用户表、角色表、菜单表、用户角色表、角色菜单表
- 后台动态加载json数据给前台。 这里的json数据，就是菜单栏的数据（就是通过后台数据查询找出当前用户拥有哪些菜单）
- 用户（操作员、管理员、超级管理员）只能看到自己对应的菜单数据
思路：sql语句加上对应的where条件 ，来对查询到的所有数据做进一步的筛选。
实现步骤：
- 设计表结构，
- 依次往菜单表、角色表、用户表中加入数据，
- 根据页面需要的数据，设计webapi接口方法，
- 通过网页操作将数据加入角色菜单 rel_rolemenu、用户角色rel_userrole的关系表中
-----------------------功能完成后的表-------------------------------
用户表
角色表
菜单表
关系表
-------------------------开发过程中发现的问题------------------------------
1. 返回当前用户的菜单按钮数据
A方式 通过关系表查询 , 这种方式查询不方便 （如果用EF的导航属性的话，实现起来还是相对简洁些的） ，但是做数据修改的时候很方便 ，可以直接对关系表做操作。
B方式 通过存储的MenuIds去菜单表中做查询，这种方式查看查询方便，但是修改不方便，需要 在 用户更新角色数据、角色更新权限数据、权限数据更新时，去更新用户表里面的MenuIds值 很是繁琐
我采用的方式：由于个人比较懒，喜欢数据能够直观些，也不太知道哪种方式好，就把2种方式都用了！ 但是个人建议，还是用第一种方式，不要弄复杂了，功能能实现就行！
事后分析总结： A方式 在表里就不需要加MenuIds、RoleIds字段来处理，直接通过 用户角色列表，操作关系表 rel_userRole、rel_roleMenu表来处理，由于我们现有公司该表没有做软删除的设计，还需要在删除 单条menuId、roleId值时，去这些关系表里删除对应的记录
B方式 实际上就不需要建关系表了， 而要加上MenuIds、RoleIds字段值，然后通过这些MenuIds、RoleIds去Menu表、Role表中找出对应的记录就可以了。 在进行menu表、role表数据进行更新时要找出它所影响的 用户数据、角色数据是哪些、然后更新这些数据的MenuIds、RoleIds值
2. 菜单表父子结构的数据
A方式 直接将表数据交给前端人员处理成树形结构
B方式 自己在后端处理这些数据，然后将处理的树形结构数据返回给前端人员，具体实现方法，我将在我的下一篇博客里写出来
