后台管理系统的导航设计归纳总结

前后台可以正式接通以后，我们就可以设计基础的几个数据库表了，菜单表、角色表、用户表、角色菜单表和用户角色表，有这5个表我们就可以搞定用户权限。

因为要开始涉及数据库操作，每个表的单表操作我们都会创建Controller、Service、Entity、Mapper、MapperXML，我们先来新建数据库表结构，先建立最基础的表结构，后续有需要再完善，毕竟使用了MybatisPlus，改变结构之后只需要在实体类加属性就好了。

用户表：

角色表：

用户角色表：

菜单表：

角色菜单表：

在用户表中插入超管账号：

引入Lombok方便写实体类

新建用户相关类：

修改完善部分登录服务代码：

重启项目调用登录，控制台输出一下内容

LoginForm(username=admin, password=21232f297a57a5a743894a0e4a801fc3)

SysUserEntity(id=1, username=admin, password=admin, salt=123456, name=超级管理员, createTime=2022-01-27T17:14:16, createBy=null, updateTime=2022-01-27T17:14:16, updateBy=null)

SaLog -->: 账号[admin]登录成功

整体登录流程就是这样了，继续完善。先确定密码加密方式：

md5(md5(password)+md5(salt))

在测试类中生成密码存到数据库中

登录接口中密码已经在前端经过md5加密，所以修改后端代码

新建菜单Controller

重启登录

OK，接下来从完善菜单管理开始逐步写。

企业网站一般都是具备网站管理后台的网站，可以根据管理后台提供的管理模块动态更新网站内容，使用网站功能，可以称作为功能性网站

企业网站管理后台设计有一个重要的原则：不需要有多么强大的功能，但是一定要有简洁方便的操作界面，方便企业录入产品或者资讯以及对于后期功能模块的添加等，这样运营维护起来大大降低了成本。

关于功能模块有很多，例如新闻发布系统，产品管理系统，会员管理系统，图片管理系统，友情链接管理系统，在线商品支付系统等。此外，营销型网站有专门的客服管理系统等。这些模块存在的价值就是能够让企业自行维护网站的内容，不需要网站的维护人员懂得专业的建站知识就能懂得网站页面的更新操作，调整、编辑、上传具体内容。

        后台主要由两部分组成，一部分是核心功能后台，前面已进行大部分描述。另一部分就是管理功能后台。

       管理功能后台基于SpringBoot的开源便利且较新的JavaEE项目开发框架，整合了springmvc + shiro + mybatis-plus + beetl + flowable多项开源技术，致力于让Java后台开发更简洁快速，实际是对基于GUNS的后台管理系统框架进行的简单改造

      一、登录界面

​

        二、   前台管理模块：管理核心功能，包括用户，群组，聊天室的增删改查，

​

        三、运营管理模块：包括内容管理，消息推送，还有运营数据统计

​

         四、系统设置模块：后台管理账户，权限，菜单，字典，登录日志，监控

​

      五、接口文档：方便前后台对接进行联调时的系统文档说明，

鉴于后台的权限，数据分级越来越细化，越来越错综复杂，我对现有的项目后台进行了一个初步的升级。参照传统的CRM管理系统改造了权限系统。

在一套后台管理系统中，系统通常会有多种需求的用户登陆。例如系统维护人员、运营分析人员、文案编辑人员、部门管理人员等等，而系统维护人员登陆要看到日志界面和服务器监控界面，文案编辑人员要看到文章界面等等，不同的用户登陆到后台还需要展示不同的菜单和界面，

单单运营分析人员，在系统中可以可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型，A分公司的运营助理只能看A公司的运营数据，C部门运营经理只能看到C部门的运营数据，大区运营总监应该要看到属于华东大区的所有公司以及部门的数据，不同人员能够查看的数据范围应该是不同的

其次，上述提到的的文案编辑人员，还会区分出总编辑，和文案撰稿人，虽然同样能看到文章管理界面，但总编辑拥有添加、编辑、删除、审核、发布等功能，普通文案只有有添加、修改的权限。

本文将对上述提到的场景提出一种基础的解决方案。

【 角色】： 系统运维、运营分析、部门职员这类拥有不同权限功能的标签，我们称之为“ 角色” 。

【 组织部门】： A分公司、C部门、华东大区、无论大小我们统称为“ 组织部门” 。

【岗位】： 运营助理、运营主管、运营经理、运营总监我们统称为“ 岗位” 。

【 数据权限】： 大区运营和部门运营所能看到的数据范围不同，我们称之为“ 数据权限”。

【 资源权限】： 文章管理撰稿人比总编辑少了审核、发布的功能，这些功能我们称之为“ 资源权限” 。

有了角色，部门组织，岗位，数据权限，资源权限这5个概念的结合就可以结合出满足一般使用场景的权限设计。

      我们将数据权限、资源权限接关联在一个角色上，然后将关联好的角色与用户绑定，这样就完成了权限对用户的分配。另外，我们也可以将角色关联在某个部门的岗位上，然后用户只要填写所属部门和岗位即可获得权限。

     比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体，我们能就可以创建成角色。但要注意的是，角色一般是可以多个同时并存的。比如创建一个新文案负责人，组织允许他既可以自己撰稿，也可以帮助别人审稿，这时候往往不会在当独为他设计一个撰稿审稿人角色，而是同时为他分配撰稿人+审稿人两个角色。这样，该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。

    岗位和角色的概念其实是挺相似的，一个岗位一定程度上代表了他在组织中的角色。然而同样的岗位在不同的组织部很可能是不同的：   例如A部门的采购主管和B部门的采购主管。同样是主管的岗位，但A采购公司规定可以查看整个部门数据、不允许查看订单，而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据，从而造成了同岗不同权。

    这时，我们可以单独为这些部门各自创建岗位，并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管， 然后我们为这个岗位预设好 “采购数据分析员”，“采购数据录入员”，“订单审核人员”的角色。 这样以来，当A公司来了一位新的采购主管，我们只要为他创建好账号，然后为他设置这个岗位就可以实现权限的绑定。

    撰稿人可以编写文章，审稿人只能查看和标记审核结果，区分两者权限不同，依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限，为审稿人角色绑定“文章:查看、文章:审核”两个资源权限，然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限，页面就隐藏掉审核的开关按钮。

    数据权限我们目前只分三种，“仅自己数据”，“部门数据”，“全部数据”。如字面含义一样，“仅自己数据”只能查看与自己直接关联的数据，比如自己的销售额，自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据，比如整个部门的销售额，部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限，一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是，数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。

   组织部门可以区分用户在系统中的不同组织、不同等级关系。比如一个平台往往可以接入众多的公司，如图

组织与组织之间有明显的层级架构关系，结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限，以及销售团队1的队长权限等等。

上述的结构只是一种方案，当然方案不可能是万能的，具体的实现还需要结合实际项目需求进行设计开发。

由于每次开发新项目都需要一个权限管理系统，为了解决重复开发让成本增加的问题，特此开发一套狼奔权限管理系统。 狼奔权限管理系统是一个项目的基础，也是复用性最高的模块，新项目可以基于此模块开发。 系统登录 提供了登陆狼奔权限管理系统的功能。 用户必须指定用户名。如果用户没有录入登陆用户名，则提示用户“请填写 用户名” 用户必须指定验证码。如果用户没有录入登陆验证码，则提示用户“验证码 错误！” 如果用户录入的用户名称或者密码不存在，提示用户“用户名或者密码出 错。” 用户密码需要使用“*”加密显示。 用户密码区分大小写。 如果用户录入的用户名

主色调色板 Daybreak Blue / 拂晓蓝

中性色板

色彩应用

更多： https://ant-design.gitee.io/docs/spec/colors-cn

何时使用

通过「小号间距」（8px）、「中号间距」（16px）、「大号间距」（24px）三种规格来划分信息层次

在这三种规格不适用的情况下，可以通过加减「基础间距」的倍数，或者增加元素（e.g. 分割线）来拉开信息层次。

—————————————————————————————————————————————

1）次按钮

常规按钮，用于非主要动作。如果 不确定选择哪种按钮，次按钮永远是最安全 的选择。

2） 主按钮

突出“完成”、“推荐”类操作； 一个按钮区最多使用一个主按钮 。

3） 文字按钮

弱化的按钮，采用更轻量的按钮样式，可用于需 大面积展示按钮场景，例如表格组件中的操作列 。

4）图标按钮

图标提供视觉线索，避免逐字阅读按钮文案，更高效地使用界面。

5）在按钮中添加图标

用于对按钮含义补充解释，提高按钮识别效率。

6 ）特殊按钮

虚线按钮、危险按钮、幽灵按钮等

将按钮区放置于用户浏览路径中，便于被用户发现，如 “F 浏览模式” 和 “Z 浏览模式” 。

什么时候需要在 Footer 中放置按钮区？（为了要和 Body 区区分开来）

按钮顺序

推荐操作是阅读的起点，折叠内容始终在最右侧。

按钮分组

布局相关：

验证导航系统 的设计好坏可对其进行压力测试：像跳伞一样跳进网站里，验证导航系统的极限。

1）忽略首页，随机直达网站某一页面；

2）看用户是否能知道当前位置以及与网站其他部分的关系。在哪个网站的哪个部分？上层网页是什么？

3）是否知道这个网页会带你到哪里去？链接文字是否能说明去向?

基础布局

页级的批量操作影响整个页面，可布置于页底。

选择模版

区隔方式

根据各个信息之间的相关性，判断各个信息模块之间的亲密度，通常情况下，相关性强的内容尽量靠近，相关性弱的的内容尽量拉开层次。

简单总结一下最主要思路和中心思想

1、首选light模式，特定情况（需要沉浸式/暗光）下选择dark暗黑模式

2、导航 按需，目的是帮助用户了解网站可用功能、当前位置、关系、去向

3、给内容区域最大的空间

4、根据内容选用合适模版、组件

5、注意布局与间距

6、注意排序、对齐、按钮、文案等

手机app后台管理系统的开发，一般都是使用php语言或者是java语言来开发的，不过要看你开发的是什么版本的app了，如IOS版本跟安卓版本的手机app他们的后台管理系统开发的方式是不同的。

一切皆于需求，后台从0开始搭建，但是写了一两个页面后发现太多的是对单表的增删改查操作，于是就想到了，能不能做一个快速搭建的后台。想到一句话，配置即一切。如果一个CURD后台能只进行配置就自动生成，该是多么美妙的事情，那么就开始搭建这么个结构。

首先配置文件应该怎么设计

起初想到将配置文件放到config目录下，但是想想还是放弃了这个想法，那样子可能会导致有一个“万能”文件，又臭又长。那么，其次，这个功能只针对单表，所以，是不是可以将配置文件放置在Model中，后来也觉得这个想法不大好，这个配置文件是承担页面展示的功能的，如果放在Model中就算是入侵了Model层了。所以最后决定放在了Controller中。

最后的效果大概是什么样子的？

后台大概会有几个页面：

列表页：

列表页中有查询操作，编辑，删除按钮，新建按钮。

新建页面：

编辑页面：

好了，对应这几个页面，我们可以设置配置项了。

基本想法是搭建一个FormController，所有以后需要配置生成后台的controller就继承这个FormController就好了。在FormController中定义属性：

class FormController extends BaseController {

// 对应的模型

protected $model

// 所有的字段

protected $fields_all

// 列表页显示的字段

protected $fields_show

// 编辑页面显示的字段

protected $fields_edit

// 创建页面显示的字段

protected $fields_create

}

定义了Model，来表示这个Controller是对那个Model进行单表操作的。

定义了fields_all属性，来将所有的字段来进行一个说明和定义。这个定义和说明就包括字段显示名字，字段是否要进行搜索，字段类型是什么。

对于列表页，不是所有属性都显示出来，所以定义一个fieldsshow，这个数组存放的是fieldsshow，这个数组存放的是fields_all中的一些字段，用来显示的字段。

对于编

首先你的确定你的校园网站要实现什么功能……

像 信息发布模块 （新闻、校园公告、教务资料、图片管理等等）

再，你要对， 各个管理员 附加 相应权限 （如校部门领导、各班主任等等，需要你细分），校园网站 少不了 会员体制，成绩查询等功能，这免不了建立 数据库，与 成绩录入等功能……

一个人设计一个太耗精力了，让学校买个商务版的吧……