关于游戏陪玩系统源码后台管理系统前端项目的思考

开发游戏陪玩系统源码后台管理系统是大部分游戏陪玩系统源码前端开发人员接触过的项目，如何更好的进行项目的搭建、组件的开发、数据结构的设计等等，这些都是需要考虑的问题。以下是我结合一些项目的经历和其他大佬的项目代码与技术分享，做出了对于后台管理系统中前端项目的思考。

1. 了解需求，熟悉掌握需求

这一要求无论是对于游戏陪玩系统源码前端开发人员或是其他端的开发人员，都是能够顺利开发项目的前提。在开发游戏陪玩系统源码之前，需对 PM 的需求了然于胸，对原型设计能够充分掌握。理解每一个操作逻辑的含义，并且扩散思维思考如何进行组件和数据结构的设计。
但是单独只是对需求文档和原型进行阅读是比较容易遗漏某些功能点的，最好能够对项目重新设计一张 思维导图 ，从开发自己的角度进行设计，从项目整体的根节点出发，细分每一个模块，每个模块下设计好对应的需求，确保每一个功能不被遗漏。虽然多花了设计思维导图的时间，但我觉得这是值得的，这样不仅仅能够增加对于整体项目的理解，也能更好的及时发现项目的难点和疑惑点。

2. 确定技术选型

游戏陪玩系统源码后台管理系统的主流技术选型为 Vue+ElemetUI，不过个人觉得在组件设计上 Ant Design Vue 的 UI 框架设计得好一些，更多的是采取数据驱动组件的设计模式，在游戏陪玩系统源码开发中可以更方便的解耦逻辑函数。不过 UI 框架的选择还是得结合开发人员团队自身对于某一个的熟练程度和是否有对应的 UI 框架能更好的解决项目中存在的难点进行综合比较。
全局按需引入 element-ui 组件：

import Vue from "vue";
···
import { Input } from "element-ui";
Vue.use(Input);

组件使用：

<el-input
  v-model="user"
  clearable
  @keyup.enter.native="search"
  @clear="search"
></el-input>

3. 设计项目结构

通过 Vue 脚手架工具搭建的前端项目在 src 文件夹下可分为以下几部分：

1. 路由层 router
2. 静态文件层 assets
3. 页面结构层 views
4. 组件结构层 components
5. 全局状态管理层 store
6. 功能逻辑处理层 util
7. 常量管理层 constants

在 游戏陪玩系统源码中还可以引入更多的配置如混入层 mixins 、过滤层 filtters 等。
在游戏陪玩系统源码开发中，需要区分开业务功能和非业务功能的逻辑设计，对于一些可以解耦出来的非业务功能函数，一般不直接在开发页面的业务逻辑中直接定义此函数，而是需要抽离出来，可供多个业务功能函数进行调用。
组件结构层 components 中一般也只开发非业务功能相关的页面组件或功能组件，以供多个页面结构进行调用，若一个页面需分成几个组件开发，且此子组件属于业务功能的，建议直接在页面结构层 views 中定义，开发和维护同一个页面也比较方便。
src 文件夹下结构如下：

├─assets
├─components
├─constants
├─mixins
├─request
├─router
├─store
├─utils
└─views

4. 数据请求 methods中 OR actions中

一般游戏陪玩系统源码中对于数据请求的方式都是基于 methods 钩子或其他生命周期钩子中调用请求方法，也存在一些项目中是通过发送一个 disptach 异步请求方法在 actions 中调用请求函数。使用后者的说法是便于统一管理请求接口，并对请求返回的数据进行统一的管理。
综合以上两种做法，可以优化游戏陪玩系统源码中的请求方式，若请求接口发出后返回的数据需要在多个页面或多个不同的组件中共享和使用，则推荐在需要发请求的函数中 dispath 触发，在 actions 中发送请求，返回的数据保存在全局状态管理 state 中。
methods 中发送请求方式：

getGraphicCode () {
  let vm = this;
  api.login.getCheckCode({
    type: '2'
  }).then(res => {
    if (res.code === '000') {
      vm.graphicCode = 'data:image/png;base64,' + res.data.img;
      vm.imgId = res.data.imgId;
    } else {
      vm.$message.error(res.msg);
    }
  })
}

actions 中发送请求方式：

findAllRoles({ commit }) {
  return new Promise((resolve, reject) => {
    api.systemAccount.findAllRoles().then(response => {
      if (response.code === "000" && response.success) {
        commit(MUTATIONS_TYPE.AllROLES, response.data)
        resolve(response);
      } else {
        reject(new Error(response.code, response.msg))
      }
    })
  })
},

5. 登录与权限管理

token 验证是目前大部分前后端分离的 游戏陪玩系统源码做登录验证比较常见的方法。前端通过发送账号和密码或账号和验证码给到后端后，后端验证通过会返回一个唯一的 token 作为该用户的登录凭证，在之后的每个请求当中，请求头中都需带上这个 token 作为后端的登录校验。
token 有过期的机制，可以在请求拦截中做逻辑判断处理，若当前时间接近了过期时间，则通过更新 token 的接口请求更新 token ，在之后的请求中带上新的 token 。以此循环，若用户过长时间无操作，则可认为用户为离线状态，在用户之后的第一次请求时，由于 token 已经过期，访问后端接口会发生错误，根据后端返回的错误状态码作为判断，将系统定向至登录页面。
通过带有 token 请求头的请求方法，游戏陪玩系统源码后端可以判断到是哪一个用户，前端也可以通过获取权限接口获得该用户的权限列表，根据游戏陪玩系统源码权限列表做一份路由映射表，如果后端返回的数据结构与前端的路由设置的数据结构不同，此时还需编写此映射路由的业务功能函数。
如果该用户拥有此路由权限，则通过在全局路由监控中 router.beforeEach 进行 router 中的 addRoutes 方法将有权限的路由配置添加到路由当中，侧边栏也可根据路由列表中的 meta 字段中关键字的判断进行相应的渲染。如果权限的颗粒度小到一个按钮，则可根据游戏陪玩系统源码后端返回的权限列表映射出的权限参数，通过 v-if 进行判断该功能组件是否渲染。
在路由管理中通过 router.beforeEach 钩子中判断当前的路由权限是否为空，是的话则可执行获取权限路由的接口：

store.dispatch("getUserInfoAndAuthorityInfo").then(res => {
  // 根据后端返回的路由权限格式转成前端路由配置格式
  const rolesRoute = setAsyncRouterMap(res.menuList, asyncRouterMap, mainChildrenAsyncRoutes)
  store.commit(Vue.VUEX_TYPES.ROLESROUTE, rolesRoute);
  // 添加路由
  router.addRoutes(rolesRoute);
  next({ ...to })
}).catch(() => {
  Message.error("验证失败")
  next('/login')
})

6. 常量枚举值管理

在游戏陪玩系统源码当中对关键的常量枚举值进行管理是非常有必要的。比如在项目当中后端用某个状态码 1 代表账号为启用状态，如果在游戏陪玩系统源码当中多次使用 ===1 去判断账号是否为启用状态，当需要更改这个状态码的时候，对于前端来说是一件十分麻烦的事情，所以可以通过把 1 赋值给一个常量，在游戏陪玩系统源码中引用这个常量，如果需要更改状态码的时候，则直接改变这个赋值给常量枚举值的状态码即可，常量的配置也可提醒开发人员此参数不可轻易修改，便于项目的维护和统一管理。一般常量枚举值的管理写在 constants 层中，常量的变量名使用大写字母编写。
状态枚举值得配置如下：

/**
 * 账号状态对照表
 * "0" 未启用 NOTUSED_CODE
 * "1" 已启用 ENABLE_CODE
 * "2" 已停用 DISABLE_CODE
 */

const NOTUSED_CODE = "0";
const ENABLE_CODE = "1";
const DISABLE_CODE = "2";

const ACCOUNT_TYPE = {
  [NOTUSED_CODE]: "未启用",
  [ENABLE_CODE]: "已启用",
  [DISABLE_CODE]: "已停用"
};

export default Object.freeze({
  NOTUSED_CODE,
  ENABLE_CODE,
  DISABLE_CODE,
  ACCOUNT_TYPE
});

7. 组件设计

游戏陪玩系统源码前端项目当中可以把展示组件分为两部分，分别为页面组件和功能组件。对于页面组件，常用于展现页面的整体内容，承担着业务逻辑的正常运行，与业务比较有强的耦合性。功能组件是用于展现和处理某一单一或某一模块的功能，功能组件并不关心页面的业务逻辑，充当着一个函数的作用，只要有输入便有对应的输出，并可在多个页面组件或功能组件中被调用。
综上，在设计游戏陪玩系统源码页面组件的时候，不仅应该考虑该组件能够正常的完成业务的功能，还要考虑其是否能够脱离业务成为一个功能组件，对于内容比较多的页面组件，可以在其同级目录下新建多个子页面组件共同构建。在设计功能组件时，需考虑组件的布局、逻辑、视图，功能组件的设计难度在于其要考虑到满足不断更新的需求变化，可扩展性，灵活性是设计的一大挑战。
页面组件目录格式如下：

8. 必要的开发文档或注释

游戏陪玩系统源码的开发文档可编写为md文件格式存放于项目的根目录，一份好的开发文档能够对项目的背景进行介绍，说明项目的结构和开发的步骤，更有利于其他开发人员参与或接手项目。
对于项目当中使用到的与业务功能耦合的逻辑函数，较为复杂的，编写函数的介绍以及使用方法，做好边界条件判断，示范输入数据以及对应的输出结果，可在项目中新建 docs 文件夹存放开发过程中的使用文档。
对于游戏陪玩系统源码非复杂功能的业务逻辑函数或非业务逻辑函数，可直接在定义函数之前编写注释，说明函数作用功能，以及对应的输入和输入参数的类型。
每次的开发过程都可当做是一个学习和总结经验的过程，对比以往的代码，我们可以思考代码结构是否能设计得更加完善，逻辑函数是否清晰且考虑边界条件，性能是否可以更加的优化。