在工作过程中，随着我们的业务越来越大，给项目的管理和维护带来了一定的困难，尤其是在人员异常变动的情况下团队，会有一些问题，项目中的问题会出现。可能在增加需求或者变更需求的时候需要调整别人写的代码的时候，不知道从何下手。其实，对于一个团队来说，良好的项目结构和编程习惯，对于团队和个人来说都是一种很大的成长。这里简单介绍一下在公司工作的三年中，公司项目的目录结构是如何不断迭代的。也发生了重大变化。我们公司的前端和后端都采用微服务架构，以减少项目之间的依赖。在团队创建初期，公司就已经有了目录结构的雏形，毕竟团队才成立不久。前端部分主要使用流行的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会将更小的图片编译成base64components：承载业务中需要用到的所有组件，使用base和业务将基础组件进一步划分为routes：编写路由结构mixins：混入store：页面状态管理style：页面和组件样式views：storepageutils：页面或组件中需要的工具，以及二次封装其他第三方工具main.js：程序的入口文件static：虽然通过上面已经为项目调整了更大的静态资源文件，但是随着业务的发展，项目还是会越来越乱，乱在哪里？第一点，所有页面的业务组件都存放在一起，查找不是特别方便。第二点是所有页面都存储在视图中。例如，用户管理可能包括用户详细信息、修改和添加。但是，这些也与其他业务页面一起存储。第三点，路由器里面的内容服务越多，业务就越大。这对项目来说也是一个很大的负担。其实上面的问题都不是特别大的问题。,可以使用文件或文件夹进行拆分，使各部分业务相对独立。在改进之前已经做了很多考虑。首先是模块之间的存储问题。使用文件夹虽然可以解决这部分问题，但是会带来资源加载的问题，比如在模块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//静态资源通过上面目录结构的调整，整个项目的内容变得更加清晰。加入域的主要目的是实现页面性能和业务逻辑的分离，将业务处理放到域中进行处理。为了节省篇幅，只说明改变文件的作用。component：只存放页面所依赖的业务组件。文件夹内部使用文件夹来划分页面和页面。domain：用于处理业务部分，比如数据提交前的处理，数据请求前的处理数据处理实例：页面的实例，属于多个页面，内部使用文件夹来划分页面中间件：Vue实例中的公共中间件，内部使用两个文件夹进行拆分，即中间件。.javascript.jspublicComponents：所有页面通用的组件。文件夹分为base和business，进一步划分业务组件和基础组件。这里需要注意一点，对于instance和routes的理解和认知，instance是以业务模块为单位，而routes是以模块功能为单位。比如实例中划分了业务A的相关内容，但是这部分业务很小，只有一页，所以此时不??需要使用路由，而业务B有一个内容很多，需要使用路由来匹配业务内容。内容进一步细分。说白了，实例的作用就是把业务和业务分开，让两个业务即使在同一个项目里也分了。但是，路线根据业务分为两次。应该属于业务的，只在业务模块的管辖范围内处理。在系统开发过程中，随着项目内容的增多，一般会带来很大的问题。当视图中有很多文件服务时，需要在页面中定义很多方法，用于业务处理。说到修改代码的使用，感觉不太爽。代码运行在一个文件上，方法之间的依赖关系是密不可分的。哈哈哈，这感觉真好吃。并且在开发过程中，写一个函数需要频繁的上下滚动。为了解决这个问题，最后考虑到页面内容较多的问题，为了实现，采用了结构和行为分离，混合的形式。在mix-in文件中添加页面业务mix-in，将views文件中的JavaScript根据页面上的业务放到对应的***.js文件中，减少页面上业务处理的js代码。调整后需要在miaxins中引入domain文件。为了在最终版本中实现结构和性能的分离，虽然使用mix-in间接解决了上述问题，但违背了mix-in的初衷。久而久之，这不是长久之计，仍需内部调整。如果没有domain之前，一切都写在了***.vue中，那我们是不是可以直接把这部分内容提取出来，直接注入到页面中呢？尝试过后是可以的，所以抽出来的部分，也就是JavaScript，还是很臃肿的。事实上，域不仅控制页面，还控制行为。将域的内容分解为控制器和服务，所有的页面表现都放入控制器统一处理和管理。这里升级了Vue脚手架，使用的是Vue3.0脚手架。├─api//数据请求├─assets//静态资源├─components//组件├─controllers//控制层├─instance//页面实例├─middleware//中间件├─mixins//混入├─publicComponents//公共组件│├─base//基础组件│└─basic//业务组件├─routers//路由├─services//业务处理├─style//Styles└─views//页面结构前端同学应该都知道，前端是通过结构（HTML）、表现（Style）、行为（JavaScript）来完成整个页面的。但是，这种调整是对原有域的二次划分，将整个页面结构、风格、行为都分开了。可能有同学会问，service、controller、view是什么关系？其实这里使用的es6类是在创建页面的时候将controller和相关服务引入到页面中的。创建页面时，同时创建控制器。当控制器被实例化时，服务以参数的形式被注入到控制器中。为什么要这样设计？当某部分业务需要临时调整时，可以直接新建一个类注入。无需更改原始代码。当业务需要改回来的时候，需要直接替换掉注入的。只是服务。test.vue {{controller.pageService.page}} {{controller.pageService.size}}
