前端项目目录结构演变

时间 2021-02-19

标签 javascript html 前端 vue java es6 web vue-cli 编程后端栏目 JavaScript 繁體版

原文原文链接

在工做过程当中随着咱们的业务愈来愈庞大，对于项目的管理和维护带来必定的难度，特别是团队中的人员存在异常变更的时候，就会出现一些问题，项目中的问题就会出现浮现出来，可能其余人写的代码在添加需求或者更改需求的时候须要调整的时候，不知道该从哪里开始入手。javascript

其实对于一个团队来讲一个良好的项目结构和编程习惯不管对于团队仍是我的来讲都是一个很大的成长。这里就简单的说在公司工做进三年的时间公司项目的目录结构是如何不断迭代的。其中也作了很大的改变。html

咱们公司不管前端仍是后端都是使用的是微服务进行架构的，为了减低项目与项目之间的依赖性。在团队建立初期公司已经有了目录结构的雏形，毕竟团队刚刚成立没有多久。前端部分主要采用的是先在较为流行的Vue，本文对于目录结构的演变一样也是针对Vue项目进行延申的。前端

目录结构雏形

在最开始建立项目初期作项目的时候整个项目状况仍是很糟糕的，数据请求都是写在**.vue文件中去请求，项目总体没有统一的规划，致使项目一旦某些内容发生改变的时候，颇有可能致使牵一发而动全身。对于项目的维护来讲简直能够用一塌糊涂来形容。vue

然而为了解决这些问题，因此对目录结构进行了第一次规划，其实此次对于目录规划主要参考了Vuex官网中的推荐的目录结构。java

├─src               //  项目目录
│  ├─api                //  数据请求
│  ├─assets             //  资源
│  │  ├─baseData            //  静态数据
│  │  └─images              //  较小图片资源
│  ├─components         //  组件
│  │    ├─base              //  基础组件
│  │    └─business          //  业务组件
│  ├─routes             //  路由
│  ├─mixins             //  混入
│  ├─store              //  状态管理
│  ├─style              //  样式
│  ├─views              //  页面
│  ├─utils              //  工具
│  └─main.js            //  入口文件
└─static            //  静态资源

这种项目结构来讲算是单页面中比较中规中矩的了，每一个文件夹中都本身作了本身的事情，对于总体项目的维护也相对来讲变得容易了一些。es6

api：主要负责提供数据请求的方法
assets：提供业务中所须要的数据资源以及较小的图片资源，vue-cli会把较小的图片编译成base64
components：承载了业务中全部须要用到的组件，使用base和business对基础组件进一步划分
routes：编写路由结构
mixins：公用代码的混入
store：页面中的状态管理
style：页面和组件样式
views：存放页面
utils：页面或组件中所须要用到的工具，以及对于其余第三方工具的二次封装
main.js：程序的入口文件
static：较大的静态资源文件

虽然经过上面的对于项目进行了调整可是随着业务的发展项目仍是会越乱，乱的地方出如今哪里？web

第一点，全部页面的业务组件全都存放在了一块儿，查找起来不是特别的方便
第二点，全部页面都存放在了views中，好比用户管理可能会有用户详情，修改，新增，然而这些又和其余的业务页面存放在了一块儿
第三点，就是router里面的内容业务越多，业务就越庞大，这对于项目来讲也是一个很大的负担

其实对于上述问题都不是什么特别大的问题，均可以使用文件或者文件夹来进行拆分使每一部分业务都作到相对的独立。vue-cli

改进

在进行以前作了很大的考虑，首先就是各个模块之间的存放问题，虽然使用文件夹进行划分能够解决这部分问题，可是随之带来的是，就是资源加载问题，好比A模块中不须要用的router，可是须要用store，可是B模块又须要用到router，不须要用到store，然而这就在加载页面资源的时候相对的会加载一些不须要的资源。通过反复的尝试，最后使用多页面与单页面相结合的形式。只在须要用到的某些资源的时候才会在vue实例中使用其对应的资源。编程

├─src                   //  项目目录
│  ├─api                    //  数据请求
│  ├─assets                 //  静态资源
│  │  ├─baseData                //  静态数据
│  │  └─images                  //  较小图片资源
│  ├─component              //  业务组件
│  ├─domain                 //  业务页面
│  ├─mixins                 //  混入
│  ├─instance               //  页面实例
│  ├─middleware             //  中间件
│  ├─publicComponents       //  公用组件
│  │    ├─base                  //  公用基础组件
│  │    └─business              //  公用业务组件
│  ├─routes                 //  路由
│  ├─views                  //  页面
│  ├─store                  //  状态管理
│  ├─styles                 //  样式
│  └─utils                  //  工具
└─static                //  静态资源

经过上面的目录结构的调整，整个项目中的内容变得更加的清晰了。加入domain主要是想要达到页面的表现和业务的逻辑相互分开，对于业务的处理放到domain中进行处理。后端

为了节约篇幅只说明改动文件做用

component：只存放页面中所依赖的业务组件，文件夹内部使用文件夹对页面与页面的划分
domain：用于处理业务部分，好比数据提交前的处理，数据请求前的数据处理
instance：页面的实例，多页面全部，内部使用文件夹对页面进行划分
middleware：Vue实例中通用的中间件，内部使用两个文件夹进行拆分，分别是middleware.style.js和middleware.javascript.js
publicComponents：全部页面公用的组件，文件夹内部分为base和business对业务组件和基础组件进一步划分

这里有一点须要注意的是，对于instance和routes的理解和认知，instance是以业务模块为单位，然而routes是一模块功能为单位的。举个栗子，instance中所划分的是业务A的相关内容，可是这部分业务不多，只有一个页面，那么这个时候就不须要用到routes，业务B内容则不少那么就须要使用routes对其中的内容进一步的划分。

说白了instance的做用就是，对业务与业务之间的划分，使两个业务虽然在同一个项目中也作了划分处理。然而routes则是在业务的基础上进行了二次划分。本该属于该业务的只在该业务模块所管辖范围内进行处理。

在系统的开发过程当中随着项目中的内容日益的增多，会广泛的带来一个很大的问题，当views中的文件业务特别多的时候就须要在页面中定义不少不少的方法，以及对于业务的处理。当去修改代码的使用，那感受简直不要太爽，一个文件上前行代码，并且方法相互之间的依赖性谁都离不开谁，哈哈哈，这感受太香了。并且在开发过程当中，写个函数须要频繁的上下滚动。为了解决这个问题最后考虑到页面中的内容较多的问题，为了实现，结构和行为相脱离使用混入的形式。

在混入文件中添加对页面业务的混入，views文件中JavaScript根据页面中的业务放到对应的***.js文件中，减小页面中的业务处理的js代码。在调整以后须要在miaxins中去引入domain文件了。

最终版本

为了实现结构与表现的分离，上面虽然使用混入间接的解决了这个问题，可是违背了混入的最初的用意，长此以往这也不是什么长久之计，仍是须要对内部进行调整，在没有出现domain以前，所有都是写在***.vue中，那么可不能够直接提取这部份内容直接注入到页面中呢？通过尝试是能够的，那么抽离的这部分也就是JavaScript仍然仍是很臃肿。

其实domain不但控制了页面仍是控制了行为，对domain的内容进行分解分为controller和service页面表现所有都放入controller统一处理和管理，service则负责单个业务的处理和页面数据的管理。

这里对Vue脚手架进行了升级，使用了Vue3.0脚手架。

├─api                   //  数据请求
├─assets                //  静态资源
├─components            //  组件
├─controllers           //  控制层
├─instance              //  页面实例
├─middleware            //  中间件
├─mixins                //  混入
├─publicComponents      //  公共组件
│  ├─base                   //  基础组件
│  └─basic                  //  业务组件
├─routers               //  路由
├─services              //  业务处理
├─style                 //  样式
└─views                 //  页面结构

前端同窗应该都知道前端经过结构(HTML)，表现(Style)，行为(JavaScript)来完成整个页面的，然而此次的调整是对原有domain的二次划分，使整个页面结构、样式、行为脱离。

可能有的同窗会问，那么service、controller和view他们之间是如何关联在一块儿的呢？其实这里使用的es6的class在页面建立的时候把controller和相关service引入到页面中，在页面建立时，同时建立controller，在controller实例化的时候把service以参数的形式注入到controller中。

为何要这样设计，当某一部分业务须要暂时调整的时候就能够直接再建立一个新的类注入进去便可，不须要更改原有代码，当业务须要变动回来的时候，直接要更换一下注入进去的service便可。

test.vue

<template>
    <div>
        <p>{{controller.pageService.page}}</p>
        <p>{{controller.pageService.size}}</p>
    </div>
</template>

<script>
import TestController from "@/controllers/test/view/TestController";
import TestService from '@/services/test/view/TestService';

export default {
    data:() => ({
        controller: new TestController(
            new TestService();
        )
    })
}
</script>

TestController.js

export default class TestController {
    constructor(pageService){
      this.pageService = pageService;
    }
}

TestService.js

export default class TestService {
    constructor(){
        this.page = 1;
        this.size = 20;
    }
}

经过对domain的拆分以后项目总体来讲不管是对页面的调整仍是拓展都变得更加的容易的了，不管业务怎么变动，即便是换套业务逻辑也不须要更改原来的代码只须要调整注入进去的实例便可。目前来讲仍是蛮香滴。

总结

本文记录一下对于项目结构的总体调整以及考虑，主要目的为了达到总体结构、表现、行为的相对脱离。经过对目录结构的调整，对于总体项目的维护与拓展有了更高的可控性。

文章略有潦草，如有什么问题请在文章下面留言。针对其业务单独写了脚手架qj-web-cli欢迎你们下载。