《vue项目》《node项目》你们更需求哪个？

通过本问将看到我在vue的项目中，进行的一系列的项目优化，然后看到不同的维度将这些点进行分类。

这里更多的指的是设计考虑的思路，是大纲，暂不涉及实际代码。

项目架构

分模块设计思想

在接到项目之后，首先将store,router，xhr的对应三个部分分别分子模块，每个子模块的划分维度有所差别。

其中store划分modules划分维度是数据关联性，由于store本身支持modules的组合，而且使用是混合在一起的，所以我们还是会在index中将模块进行混入的。
其中router是按照业务进行分模块的，或者说是按照页面维度分的，每个一级路由分一个路由模块，二级路由为页面名称，其中将一级路由设置为文件夹名称，二级路由路径与页面名称同名，为了简化这部分，一级路由的名称定为‘scope’，而且为了同时支持懒加载和优化引入组件的写法，写了_import的优化方法，可以批量按照文件名引入对应的组件，在生产环境将进行路由代码分割。然后不同模块也是最后汇总到router的modules中。
其中xhr的部分按照后端的微服务进行拆分模块，方便查看和维护。按照后端的接口层次再决定是否划分二级对象属性，其中暴露出来的方法与后端同名，后续也是决定采用easymock进行批量生成api方法来优化这部分手写代码的工作。考虑到几乎没有一个页面或者组件会用到多余两个的api微服务请求，所以这就决定了我在index.js中并没有收集聚合每个业务的api，而是选择开发时按需加载。而对于通用性比较高的api，我一方面会定义在index.js中，另一方面会把这部分数据暴露在vuex中来达到目的。
额外介绍，除了以上三个，我针对src根目录也设置了过滤器的分业务模块实现方案。这部分由于各个业务耦合情况比较少，所以也是仅仅针对核心的工具过滤器暴露在index.js中，其他的都是按需引入。
业务内公共组件

与有的同学考虑不同的是，我在写一些组件的时候，针对业务性比较强，但是针对当前业务公用的一些拆分组件会定义在每个业务的components目录下，而不是放在src/components,我称之业务内公共组件。

业务内枚举 与 全局枚举

其实很多时候会遇到枚举数据，或者是后端定义好的，或者是前端定义好的，或者是接口请求的但是基本不做更改的。也许枚举字段少的也还好，但如果一个数据项有超过十个枚举项，有超过2个页面使用的时候，你应该考虑的是单独的放在枚举字典文件中去维护。 那么首先，我是建议基于这个业务的枚举建在业务的根目录下新建一个enum的js枚举文件，单独用来承载业务中的枚举。但较多时候会有一些比较让人烦恼的部分：

1 业务中的枚举发现另外的页面中也有用，不单单属于这个一级业务页面。那么你可以这样考虑下：首先肯定是维护一份数据的，那么维护在哪里，如果是核心业务，那就维护在全局枚举仓库，然后业务中进行按需引入或者改装。如果是周边业务，偶尔用下，我个人觉得维护在业务中的枚举是比较好的。

2 枚举与过滤器与字段翻译的关系。其实枚举字段不仅仅是用于做枚举的，还必然的会充当一些下拉框，显示值的遍历来源，也可以当做字段翻译的翻译来源，同时还可以当做我们一些业务字段的过滤器。这部分理解好之后，对于我们优化整理项目中的业务数据类型有着极大的好处。

3 全局枚举业务过滤器，通用性过滤器，当然这些过滤器功能除了按照基本的部分，还会按照业务中收集到的部分进行业务过滤器的维护。同时也作为对应的方法来获得对应值转换值的语法，一者两得。

common组件

纯ui组件，elementui组件进行进一步的封装，按照其官方的维护方式进行自己项目需求的