系统框架

管理平台项目框架目标使用规范说明及部分系统 API 描述，适用于各类管理平台项目

目录结构描述

项目结构目录树如下

project/
│  .browserslistrc   浏览器版本配置
│  .editorconfig     编辑器配置
│  .env.development  开发环境下使用的环境变量配置文件
│  .env.production   生产环境下使用的环境变量配置文件
│  .env.test         单元测试环境下使用的环境变量配置文件
│  .eslintrc.js      ESLint 配置
│  .gitignore        设置 git 忽略上传的内容
│  babel.config.js   项目脚本兼容版本设置
│  cypress.json      cypress 配置文件
│  Dockerfile        docker 配置文件
│  package.json      项目总体描述及依赖描述
│  postcss.config.js 预编译样式
│  vue.config.js     vue-cli 脚手架配置及 webpack 配置
│ 
├─public        静态资源文件目录
│   favicon.ico 网站图标
│   index.html  网站实际入口
│ 
├─src
│  │  main.js   项目主入口
│  │ 
│  ├─assets     项目相关资产 / 附件，通常用于存放图片资源
│  │ 
│  ├─business   业务处理逻辑、框架相关 API
│  │ 
│  ├─components 通用组件
│  │ 
│  ├─modules    业务功能模块组件
│  │ 
│  ├─config 项目相关配置
│  │    constants.js       常量配置
│  │    directives.js      自定义指令集配置
│  │    element-plugins.js element-ui 插件配置
│  │    menu-path.js       系统菜单及路由匹配关系
│  │    plugins.js         项目中除 element-ui 外的插件引用配置
│  │    polyfill.js        自定义脚本兼容
│  │    validateData.js    自定义表单校验规则
│  │ 
│  ├─layout  整体布局结构
│  │ 
│  ├─router  vue-router 路由配置
│  │ 
│  ├─store   vuex 与本地缓存的相关处理
│  │ 
│  ├─styles  自定义样式文件收纳
│  │ 
│  ├─utils   工具类
│  │ 
│  └─views   系统业务功能页面
│ 
└─tests              测试模块
    ├─e2e            端对端测试
    │ 
    ├─sample         部分数据样例
    │ 
    └─unit           单元测试
        .eslintrc.js 针对单元测试的 eslint 配置
        setup.js     单元测试的前置处理

目录说明

部分目录功能作用说明

components 通用组件

项目内通用组件，该目录下维护的组件应尽可能不与业务内容耦合，仅提供通用功能。例如项目中统一使用的弹出窗口组件、文件上传或图片相册展示等

modules 业务模块组件

业务通用模块组件，modules 与 components 的区别在于该目录中维护的组件，存在根据业务定制了功能、操作形式或数据结构的，是耦合了部分业务内容的通用模块，也可以是由多个组件组合而成的一个组件集。例如

• 存在多处应用的商品、人员详情
• 组合了快速搜索与列表、表格的模块
• 自定义了节点展示与交互方式的树

layout 布局相关

项目的布局相关内容维护于该目录，仅维护布局结构与相关功能，不涉及容器内的功能实现

下例中，使用具名插槽的方式定义了 AdminLayout.vue 的布局组件

<template>
  <div class="..." style="...">
    <div>
      <slot name="header" />
    </div>
    <div>
      <slot name="aside" />
    </div>
    <div>
      <slot />
    </div>
  </div>
</template>

设置布局区域、样式并定义功能区域为具名插槽

将 AdminLayout.vue 布局应用于项目主页

<template>
  <AdminLayout>
    <!-- 头部具名插槽 -->
    <template #header>
      ...
    </template>
    <!-- 侧边栏具名插槽 -->
    <template #aside>
      ...
    </template>

    <route-view />
  </AdminLayout>
</template>

<script>
import AdminLayout from '@/layout/AdminLayout.vue'
export default {
  components: {
    AdminLayout
  }
}
</script>

如此，在将头部、侧边栏等公共区域内容以独立模块进行管理维护后，将相应的组件放入对应的插槽即可完成布局使用

business 业务公共定义

业务公共常量、业务间对接或公共业务函数内容

业务公共定义模块，更大的作用是起到统一定义/注册，统一调度的目的

业务公共常量

项目内公共常量定义与使用

对于项目中应用的固定文本或值，推荐使用常量维护的方式而不是将常量值硬编码于业务代码中；即便该常量并不存在多处引用的情况，将常量内容进行统一维护统一引用，也更方便项目业务迭代时，对相关内容做出快速定位与修改

// src/business/constants.js

export const DEFAULT_PAGE_SIZE = 10
export const LOADING_TEXT = '数据加载中，请稍候……'
// 限制文件上传容量（50M）
export const FILE_UPLOAD_SIZE_LIMIT = 50 * 1024 * 1024
// 字段类型
export const DATA_TYPE_STRING = 'STRING'
export const DATA_TYPE_INT = 'INT'
export const DATA_TYPE_FLOAT = 'FLOAT'
export const DATA_TYPE_BIGINT = 'BIGINT'
export const DATA_TYPE_DATE = 'DATE'
export const DATA_TYPE_DATETIME = 'DATETIME'
...

上面是一组常量定义的示例，在业务代码中则直接引用这些定义的常量；如上所述，后续的业务迭代中若有内容调整，仅需在此处进行统一维护即可

格式

通常情况下，对于常量的书写方式为全大写格式，单词间使用下划线隔开

公共业务函数

业务相关处理函数，注意与 utils 目录内容的区别，utils 目录中维护的是业务无关性的工具类

例如某种业务编码的生成函数，业务状态的检查函数等

业务间对接

业务模块间功能对接，指的是业务模块之间存在部分资源互相调用时，被调用模块在 business 模块进行定义/注册，而调用模块也同样在 business 模块进行资源获取

下面通过一个简单的示例来描述对接的处理

用户管理模块在 business 模块中注册了 loadUserProfile 的加载用户详情的函数

// src/business/user.js

import { getUser } from '@/view/user'

export function loadUserProfile (id) {
  return getUser(id)
}

在订单管理模块中，有个显示用户详情的弹窗

<!-- src/view/order/user/UserProfile.vue -->
<template>
  <Dialog>
    <div>Name</div>
    <div v-text="detail.name" />

    ... 用户详情
  </Dialog>
</template>

<script>
import { loadUserProfile } from '@/business/user'

export default {
  data () {
    return {
      userId: 10,
      detail: {}
    }
  },
  beforeMounted () {
    loadUserProfile(this.userId)
      .then(resp => {
        this.detail = resp
      })
  }
}
</script>

此处直接在 business 业务模块获取了用户管理模块注册的读取用户详情的功能函数，而不是直接去用户管理模块引用相关功能代码

业务间对接虽不可避免会存在增加部分代码定义和维护的工作，但其业务调用路径单一、清晰，避免业务间交错引用的问题，为业务的独立维护，业务剥离提供了较好的设计基础