TypeScript写的Vue项目结构分析

好久没用TypeScript写Vue项目了。刚开始使用TypeScript时，我很茫然。灵活，因为TypeScript对代码的限制太多，在写代码的过程中时不时会抛出意想不到的错误。这一点也是笔者的一大坑。可以用TypeScript一段时间，才知道TypeScript真香（无人能逃的真香定理，O(∩_∩)O）。笔者之前在使用Vue的时候，提到过如何在项目中使用依赖注入的概念。使用依赖注入有两个主要目的：解放Vuex以将页面性能和业务逻辑相互分离。同样在使用TypeScript写项目的过程中也用到了这种思路，只是有些不同。作者将项目结构划分如下：├─api//请求数据接口├─assets//静态资源├─components//组件│├─base//基础组件│└─business//业务组件├─domain//业务逻辑├─interface//接口│├─other//其他接口│├─public//公共接口│└─views//页面接口├─middleware//中间件├─mixins//混合层├─router//路由层├─store//全局状态管理├─style//样式│├─components//组件│├─base//基础组件风格││└─business//业务组件风格│├─public//通用样式│└─views//页面样式└─views//页面是这样的，每一层都有自己的职责对项目的影响只是相互依赖，对项目的维护非常友好。这里会有一个疑问，为什么要划分项目结构呢？笔者的理解是：降低功能间的耦合度，灵活部署模块间的依赖关系，各模块各司其职，使项目有利于维护和团队协作。也有人说，层与层之间存在依赖关系，它们之间是如何相互依赖的，应该如何部署呢？对于前端来说，不管是什么项目，都是依赖页面来开始工作的，所以一定要以views层为中心，而views需要依赖router，需要注入router进入vue实例。上图中没有提到资产。对于用于存放一些静态文件的assets，尽量不要将这一层与基础组件耦合。这样，如果其他项目使用了这个组件，这个组件就变味了。其实作者这里想强调的是domain和view之间的引用，对我来说，业务层就是用来拆分业务的，让view和domain各干各的，而view更注重页。如何展示数据，但是domain更关注业务逻辑部分。domeDomain.ts//从“@/api/domainAPI.ts”导入apiimportdomeAPI;//从“@/interface/domeInterface.ts”导入intaerfaceimport{tableItemInterface,queryDataInterface};classDomeDomain{publicasyncgetTableList(target:Object,propertyName:string,propertyDescriptor:PropertyDescriptor):PropertyDescriptor{constdata:queryDataInterface=propertyDescriptor.value();propertyDescriptor.value=asyncfunction():Promise{//这里是业务通讯const{result:tableItemInterface[]}=awaitdomeAPI.getTableList(data);返回结果为Promise;}返回属性描述符；}}exportdefaultDomeDomain;dome.vue在上面的代码中，domeDomain中定义了一个getTableList的方法，因为这个地方需要用修饰符来修改请求数据的方法，但是页面中的方法是可以无限复用的，调用方法的时候也可以调整它的参数那么就不用担心了关于在发出数据请求时传递参数。只需要整合所有的参数，调用对应的获取数据的方法即可，非常方便。也实现了业务和页面性能的拆分。但好处不止于此。相应的，项目中的store也被释放了。让商店做它应该做的事。如果只是为了拆分业务，不局限于这种方式，也可以直接在页面中使用领域业务类的实例调用实例的方法，或者使用mix-in来混合业务部分以mix-in的形式出现在相应的页面上。装饰器还有很多更高级的用法，我也在不断探索。我个人认为这些东西对项目的发展是有好处的。写这篇文章只是为了和更多的同学交流学习。如果文章中有什么不对的地方，可以在下方留言讨论。