关于界面主菜单生成逻辑的各种设计讨论

主菜单,就是那种后台管理系统里面,通过配置可以控制是否显示某菜单,或某菜单里的某个功能。
关于它的设计和实现方式,我个人总结大概有以下几种。

(1)用数据库表保存
一般主菜单都是树结构,基于用传统关系型数据库来保存的方案,有2种。

  • (1-1)用1个表的方案,则表里面包含1个id和parentid来关联父子关系。

  • (1-2)用2个表的方案,则1个表用来记录菜单父子关系,另一个表纯记录菜单的信息。

数据传递方案也有2种:

  • (1-1-1)后端查询出数据,通过后台代码循环构建,或者用sql事务构建好树结构,再传递给前端

  • (1-1-2)后端查询出数据,传给前端,让前端自行构建树结构

(2)用json保存
这个是我这个问题主要想了解的方式,不知道你们是否有用过,则直接把主菜单的父子节点信息构建成json格式,存到一个配置表里,或者一个json文件里。这样可以免去构造树结构的麻烦。但是由于是纯json格式,人工维护的话,数据结构不复杂的情况下还可以,如果遇到复杂的情况,可能需要编写一个维护界面来维护,这时候由于json并没有类似sql的查询语法,前端(假设是js)写增删查改起来会特别复杂(特别是删除)。

这个。。。。不知道你们平时用的是什么方式?可以的话希望可以简要的说说,
同时,如果对(2)用json保存这种方式有什么看法的话,也可以说说。
综合考虑性能,可扩展性,可维护性等等。

阅读 4.2k
4 个回答

方案选型上面两位已经说了,这里说说数据库表存储树结构关系的具体实现。

同一张表存储时,仅存储parent_id是不够的。考虑一下以下的场景。

  1. 查询某个节点的所有子孙节点。

  2. 查询某个节点的路径。

...

只有父id的情况下均需要递归查询,查询与构建都非常麻烦。

一般在数据库中存储树形结构的数据是采用预排序遍历树算法,可以google一下相关的资料。或者在层级深度不够深的情况下,可以参考如下的形式:树状结构的数据表如何设计?

方案要根据技术来选,就你给出的两种方案来说,第一种更适合关系型数据库实现,第二种更适合 NoSQL 数据库实现。

综合来看更推荐第一种方案,将菜单结构 flatten 在后期设计用户、用户组、权限等模块的时候会比较方便。而使用 JSON 的方案进行这些操作就会比较复杂。

技术只是工具,或者说是途径。
真正决定怎么做的还是要看业务。
比如一些系统的菜单需要根据权限来控制用户看到的菜单的条目,考虑到扩展性,会提供菜单编辑功能,辅以用户对菜单的可读性来控制最终的结果。

当然类似一些对菜单动态行要求没那么高的系统来说,JSON保存然后前台解析也不是不可以。

法无定法,关键看需求,看成本,看开发人员的熟悉程度。

单纯讨论技术,要我说,不如每一种都会玩,需要的时候,拿出来就好了。

菜单保存有更简单的方法,直接存一个菜单代码,菜单代码有层次关系,比如:

01 一级菜单
01.01 二级菜单
01.01.01 三级菜单
01.01.02 三级菜单
01.02 二级菜单
02 一级菜单

别用什么parentId了,当要修改整个树结构的时候很麻烦的。

推荐问题
logo
Microsoft
子站问答
访问
宣传栏