关于javascript:前端项目目录结构演变

在工作过程中随着咱们的业务越来越宏大，对于我的项目的治理和保护带来肯定的难度，特地是团队中的人员存在异样变动的时候，就会呈现一些问题，我的项目中的问题就会呈现浮现进去，可能其他人写的代码在增加需要或者更改需要的时候须要调整的时候，不晓得该从哪里开始动手。

其实对于一个团队来说一个良好的我的项目构造和编程习惯无论对于团队还是集体来说都是一个很大的成长。这里就简略的说在公司工作进三年的工夫公司我的项目的目录构造是如何一直迭代的。其中也做了很大的扭转。

咱们公司无论前端还是后端都是应用的是微服务进行架构的，为了减低我的项目与我的项目之间的依赖性。在团队创立初期公司曾经有了目录构造的雏形，毕竟团队刚刚成立没有多久。前端局部次要采纳的是先在较为风行的 Vue，本文对于目录构造的演变同样也是针对Vue 我的项目进行延申的。

目录构造雏形

在最开始创立我的项目初期做我的项目的时候整个我的项目状况还是很蹩脚的，数据申请都是写在 **.vue 文件中去申请，我的项目整体没有对立的布局，导致我的项目一旦某些内容产生扭转的时候，很有可能导致牵一发而动全身。对于我的项目的保护来说几乎能够用一塌糊涂来形容。

然而为了解决这些问题，所以对目录构造进行了第一次布局，其实这次对于目录布局次要参考了 Vuex 官网中的举荐的目录构造。

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

这种我的项目构造来说算是单页面中比拟中规中矩的了，每个文件夹中都本人做了本人的事件，对于整体我的项目的保护也相对来说变得容易了一些。

api：次要负责提供数据申请的办法
assets：提供业务中所须要的数据资源以及较小的图片资源，vue-cli会把较小的图片编译成base64
components：承载了业务中所有须要用到的组件，应用 base 和business对根底组件进一步划分
routes：编写路由构造
mixins：专用代码的混入
store：页面中的状态治理
style：页面和组件款式
views：寄存页面
utils：页面或组件中所须要用到的工具，以及对于其余第三方工具的二次封装
main.js：程序的入口文件
static：较大的动态资源文件

尽管通过下面的对于我的项目进行了调整然而随着业务的倒退我的项目还是会越乱，乱的中央呈现在哪里？

第一点，所有页面的业务组件全都寄存在了一起，查找起来不是特地的不便
第二点，所有页面都寄存在了 views 中，比方用户治理可能会有用户详情，批改，新增，然而这些又和其余的业务页面寄存在了一起
第三点，就是 router 外面的内容业务越多，业务就越宏大，这对于我的项目来说也是一个很大的累赘

其实对于上述问题都不是什么特地大的问题，都能够应用文件或者文件夹来进行拆分使每一部分业务都做到绝对的独立。

改良

在进行之前做了很大的思考，首先就是各个模块之间的寄存问题，尽管应用文件夹进行划分能够解决这部分问题，然而随之带来的是，就是资源加载问题，比方 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 欢送大家下载。