后台管理系统设计几次升级记录

前言

    本文是学习了 抖音 “哲玄前端”，《大前端全栈实践课》 后，结合以前对后台管理系统开发设计做一次整体的梳理和记录，一共分为3次升级，4个版本，开发效率分别提升为20%， 50%，80%。下文讲解的架构图中，绿色部分为自定义内容，黄色部分为沉淀内容无需开发，即节省时间的部分。本文只记录设计架构的内容，无代码实现，最后一次的升级，实现层面的内容会在另一文中详情讲解。

正文

    最古老的后台系统开发我是使用的 element-ui 组件库，然后一个页面一个页面写，当然可能大部分人都没有这样开发过，费时费力，纯的不能在纯的 crud, 整个网站都是从0-1，根据需求一个菜单一个菜单写出来，花大量的时间写着重复的工作，有新项目来就是复制以前的项目修改使用。

优缺点：
优：根本没有啥优点，就是纯纯的体力活
缺：都是缺点，费时费力。

架构图如下:

第一次升级

经过一段时间的使用，也接触了一些开源后台的代码，对原有的架构进行调整升级，把大量的重复的工作抽离成公共组件，放在项目中，组件组成包含：业务组件--bg-curd-table, 元素组件--bg-form、bg-detail、bg-table, 对外开放表单内容插槽，表格内容插槽，搜索、删除等配置。 然后把整个项目基础部分整理成模版放于公司git仓库，每次有新项目时候拉取模版，然后进行二次开发, 项目整体开发效率提升20%。

优缺点：
优：减少了部分重复性工作，提升了项目开发效率。
缺：当我组件增加一个功能，且如果多个项目需要这个功能，就需要多个项目修改，还是有一定的重复性工作存在。

架构图如下：

相关配置(部分)：

detailProps: {
    detailApi: '',
    params: {}
} //详情配置
tableQuery: {} // 表格请求参数
listApi: '' // 表格请求接口
searchFields: [] // 搜索内容配置
deleteProps: {} // 删除相关配置
... // 其他一些配置

第二次升级

又经过一段时间的使用，总结了遇到的问题，再次进行第二次升级，此次升级的工作为把核心组件抽离成组件库并发布成npm包，组件分别为：业务组件--xb-curd-table, 核心组件：xb-search、xb-submit、xb=form、xb-upload。组件开发多个插槽，多种生命周期钩子(表格结构请求前后，表单提交请求前后...)，表单实现多种联动(值，显隐，禁用..), 最后配合后台基础模板使用，通过json配置实现项目快速开发。

优缺点：
优：解决了上个版本组件更新多个项目同步问题，减少50%的开发时间。 缺: 每有一个项目都需从头开始写，无领域沉淀，整体设计重页面层面出发，即页面需要什么就加什么配置，导致字段配置的重复工作，如一个页面有tabLe,seach,detail,form.那么同一个字段就需要配置4个方

架构整体和上面项目，只是抽离了更多的配置项目，架构图如下：

相关配置(部分)：

// 表单相关配置
formConfig: {
    ...
    footerConfig:{...}, // 底部按钮
    add: { // 新增相关配置
        api: '', // 接口
        paramsFormat: () => {}, // 提交前钩子
        responseFormat: () => {} // 提交后钩子
    }
    edit: {...}, // 编辑相关配置
    save: {...}, // 保存相关配置
    formItems:[
        {
            type: '', 
            linkShowProps: '' // 联动配置
            linkShowCb
            ...
        },
        ...
    ] // 表单元素配置
}
// 表格相关配置　
tableConfig: {
   requestApi: '', // 接口
   operationConfig: {...} // 操作按钮相关配置
   deleteConfig: {...} // 删除相关配置
   columns: [
      {
          label
          props: '
          ...
      }
   ], // 表格显示 el-table-column 配置
}

第三次升级

本次升级是学了抖音 “哲玄前端”，《大前端全栈实践课》 后进行的一次全面的升级，该架构设计与原来的设计完全不在一个层面，该架构设计将更加的收拢，更灵活，更全面。主要总结为以下几点不同：

1.使用层面

• 原来的设计--使用层面在项目层面，即所有设计服务于一个项目，导致的问题换一个类似的项目还是需要从0开始开发，如果有相同的需要复制黏贴
• 现在的设计--使用层面在领域层面，该系统设计了能够解析领域模型的能力，我们只需沉淀一个个的领域模型，如电商，教育等，当我们拿到一个项目时，只需要继承对应的领域模型，该项目将无需开发相同部分的功能，只需要开发不同部分的内容即可，更准确的说现在的设计产出的是一个框架，开发可以用该框架生产出各种项目

2.DSL层面

• 原来的设计--原来的DSL设计是从页面出发，页面有什么功能就设计对应的DSL，如页面有table、search、detail、form, 那么需要对每个功能设计一套DSL, 最大的问题如果一个字段在多个功能中用到，就会造成很多重复的配置，造成代码的冗余，增加开发和维护成本，且该设计只有路由下页面部分，开发一个项目还需要clone模板。
• 现在的系统--现在的DSL设计是从数据出发，一个一对多的设计，即该字段在哪个功能中使用就在该字段的配置中配置对应的功能，　且配置严格符合jsonSchema规范，在其基础上进行扩展，除了路由下页面部分，该系统的DSL是整个项目，包含导航，头部等，无需其他模板配合。

3. BFF层

• 原来的设计--无BFF层设计，如果有页面数据方面的问题只能找你的后端同事帮你修改，虽然开发了很多格式化数据的钩子函数，但是一个是麻烦不好维护，另一个是总有无法满足的情况。
• 现在的设计--含有BFF层的设计，你可以自由的设计你需要的数据结构和*接口风格(RESTful规范)*等。

4.灵活性

• 原来的设计--灵活性方面只有个别的核心部分插槽，终有一天会在败北给产品经理。
• 现在的设计--灵活性方面大可以到整个模板，小可以到一个组件，都可以自定义。

架构图因课程版权无法展出

相关配置(部分)：

{
  mode: '', // 模版类型
  // 菜单
  menu: [
    ...
    meunType: '', // 枚举值， group / module
    // 当 meunType 为 group 时，可填
    subMenu: [...],
    // 当 meunType 为 module 时，可填
    moduleType: '', // 枚举值， sider iframe / custom /schema
    ...
    // 当 moduleType 为 schema 时，
    schemaConfig: {
      api: '', // 数据源API (遵循 RESTful 规范)
      schema: {
        type: 'object',
        properties: {
          key: {
            ...schema, // 标准 schema 配置
            ...
            // 字段在 table 中的相关配置
            tableOption: {...}
            // 字段在 search-bar 中的相关配置
            searchOption: {...}
            ...
          }
        },
        require: [], // 标记哪些字段是必填项
      },
      // table 相关配置, 如按钮等
      tableConfig: {...}
      // search-bar 相关配置
      saerchConfig: {...}, 
      // 动态组件 相关配置
      componentConfig: {...}
    }
  ]
}

总结

以上就是所有的经历，对后台管理系统架构的设计和理解，有可能存在问题，如果发现会及时修正，最后部分详细实现能写的部分会在下一文章中讲解。

注：抖音 “哲玄前端”，《大前端全栈实践课》