vue 后台管理类项目阶段性总结（1）

之前的博客应该有说过了，公司打算尝试下是用vue搭建后台管理类系统的前端框架，目前大致已经完成了2个项目，但是目前项目还在开发当中，可能还会遇到新的问题，现就目前开发阶段的问题进行一个阶段总结。

使用iview-admin还是通过vue-cli生成项目

建议使用vu-cli生成项目，这样对项目的把控程度会更高一点，后期升级会方便一点，为什么要考虑到后期升级，之前做过一个项目使用的是react0.16版本，写了一段时间之后，ES6大面积的普及，react早就升级了几个大版本，项目后期遇到问题，你想找个解决的办法，发现自己的版本太旧，根本就没人会讨论，想要项目的可持续的维护，定期的升级版本还是必要的。

iview-admin是一个很好的模板，但是我们需要考虑的是我们是否需要他，并且使用iview-admin是不是能够减少工作量，如果你遇到以下的2点，你就需要慎重的考虑是否直接使用iview-admin初始化项目：

• 客户存在大量的UI定制需求

• 公司存在一个稳定的后端框架，提供的数据格式与iview的前端数据格式不一致

项目结构

├─build                                          // webpack打包配置文件
├─config                                         // webpack各种运行模式的配置文件
├─dist                                           // 打包之后生成的文件
├─src                                            // 项目相关的源码所在位置
│  ├─assets                                      // vue-cli生成的没用到
│  ├─components                                  // 在整个项目中都会用到的通用组件
│  ├─iconfont                                    // 引入阿里图标弥补UI组件库自带图标不足的问题
│  ├─images                                      // 前端图片资源
│  ├─mixin                                       // 整个项目中通用的mixin
│  ├─router                                      // 前端路由
│  ├─store                                       // vuex
│  │  └─modules
│  ├─template                                    // 在项目中通用的模板页面
│  ├─utils                                       // 项目中通用的工具函数
│  │  └─vueplugin                                // vue插件
│  └─views                                       // 前端页面位置
│      └─mis                                     // 每个子项目在mis下创建一个文件夹
│          ├─components                          // 在子项目中通用的组件
│          ├─exception                           // 子项目异常跳转页面
│          ├─test                                // 子项目中用于测试的页面
│          └─workspace                           // 子项目模块
│              ├─components                      // 子项目模块组件
│              ├─config                          // 子项目模块配置参数文件
│              ├─mixin                           // 子项目模块mixin
│              └─mock                            // 子项目模块模拟说句
├─static                                         // 第三方静态资源
└─test                                           // 前端测试相关
    ├─e2e
    └─unit

为什么采用这样的结构？

考虑到是后台管理类项目，那么项目中必然会存在大量的重复代码，如果以项目为单位，那么我们会将项目的重复代码抽象为组件和mixin存放在最外层的components和mixin文件夹当中，以此类推，子项目和各个模块。

选择UI库

选择好的UI库可以减少很多的开发量，最终我们选择了iview UI库，至于为什么？UI设计相对来说比较的现代，是国产的UI库，我们系统的使用者是政府单位，相较于vuetify我相信iview更容易接受；

这是第一点，基于政府项目的出发点，页面主要是列表页和表单页，iview已经满足了这些要求，列表功能完善，表单组件较全，表单的校验也比较的完善。

基于以上2点我选择了iview。

数据提交与获取拦截

我们为什么要减少重复代码，面对重复代码，如果我们有一处地方需要修改，那么我们需要修改很多地方，代码的可维护性就会变得比较差，我们需要对前端数据进行处理，只要处理2处即可，把前端应用看作是一个数据展示采集的机器，那么我们只需要处理好展示的数据源头和采集的数据源头就可以了，这2处分别对应的是前端从后端获取数据，前端向后端发送数据。

明确的来说是在前端向后端发送数据和前端接受后端提供的数据中间提供一层拦截，所有的问题都在这个环节处理，所用ajax请求我们采用的是axios，通过设置axios的拦截器实现以上功能。

我们可以在拦截器中做什么呢？

我们可以在拦截器中转化数据格式，拦截失败或者未授权的请求，具体的代码将不再展示。

vue页面开发的三种模式

使用vue我们听到最多的一种开发模式应该是组件式开发，组件式开发将页面的各个组成部分抽象为组件，通过组件的拼装来开发页面，这是为什么要引入UI组件库，基于vue，我在页面开发过程中还会使用到vue的mixin 和 extends这2个API来进一步加速和规范开发。

Javascript是一门弱类型的语言，我们在享受弱类型带来的便利时同样的也要面对弱类型在开发是带来的一些问题，比如说规范问题，我们无法保证每个人创建的页面的规范性，

为什么使用mixin ,我使用他的原因是为了降低代码量，降低代码的耦合，是代码更清晰，分工更方便，我刚开始接触前端的时候写的是react，那时候单文件的代码行数我能写到1000多行，由于使用JSX,许多的逻辑时间写在JSX当中，写的时候是很爽，当时刚写完回头一看就蒙蔽了，方法写了无数个，找起来也不方便，后来接触了mixin,开始逐渐的将一个个的功能进行剥离到别的文件当中，代码清晰了不少。

在后台管理类的项目中，列表页的查询是可以通用的，我们将列表页的查询进行抽象，那就是一个请求接口获取数据的过程，不同点在哪里，查询接口的地址，查询的参数，就这2点不同，我们完全可以将这部分的代码抽象到mixin当中，所有的页面都可以引入这个mixin，我们在每个文件上要做的只是填写查询的地址，查询参数完全可以通过页面交互生成，所以我将列表至详情页的通用逻辑都写到mixin当中。

使用mixin，是因为mixin中的代码是通用的，是轻易不会修改的，为什么使用extends，我主要有以下的2中场景：

• 组件的UI需要定制化，但是页面的逻辑基本未变

• UI库章的部分组件需要修复或是扩展

我们在使用组件进行开发的时候，通过设置组件属性来实现一些交互或是初始化，但是我们对组件的控制度只能到组件对外暴露的那些属性上，如果我们需要更为深入的定制组件该怎么办，我们可以通过extendsAPI来重写组件的所用属性。