@Daotin 简单的方案容易上手，却不容易适应项目的膨胀。为什么许多项目，代码一多就乱，就是因为前期没有规划，怎么简单怎么来。可以看一下这篇文章：为什么需要 Vue3+IOC： https://front.cabloy.com/zh/guide/start/why.html

@ceilingyear 一个文件确实能解决问题，但是使用三个文件是为了解耦合，以便更好的适应业务的膨胀。
1. index.vue：在这个文件中，使用 vue3 的语法糖定义组件的 props 和 emits
2. mother.ts：一个 vue 组件实例对应一个 ioc 容器。该容器与 Vue 组件实例绑定，在这个容器中的所有 Class 实例都可以在组件实例范围之内共享数据和逻辑。那么，mother class 就是这个 ioc 容器中的第一个 class 。组件的业务逻辑就从这里展开
3. render.tsx：在这个 render class 中编写 tsx 代码，实现界面渲染。在一个独立的文件中书写 tsx 代码，从而让 tsx 代码更加舒展、从容。不知你是否有如此体验：如果仅仅在一个 SFC 文件写 tsx 代码，总是很局促的。当业务比较复杂的时候，展开很麻烦，代码逻辑不容易区分开

此外，Cabloy-Front 所采用的 class 机制，与社区现有的多个 class 方案有本质的区别，因此，逻辑更清晰，代码更优雅。可以看一下这篇文章：为什么需要 Vue3+IOC： https://front.cabloy.com/zh/guide/start/why.html

@humbass 更准确的说法是，ioc 容器和 oop 适合业务领域的建模和抽象。后端采用 ioc 容器自是当然。如果前端项目比较大，业务复杂，引入 IOC 容器可以简化业务设计。此外，Cabloy-Front 采用依赖注入和依赖查找相结合的方式，大量减少装饰器的使用，让代码更简洁、更优雅。优先使用依赖查找的机制可以达到化类型于无形的效果？简而言之，就是无须标注类型，却能享受到“类型约束”和“智能提示”的好处。这个是基于 Typescript 的强大类型系统实现的，在 java 中很难做到，因此大家普遍认为 java 很繁琐，就很好理解了。

@charlie21 cabloy-front 提供了两类 container ，一类如你所说是 global container ，实现全局状态的消费，可以直接代替 pinia 的能力。还有一类是组件 container ，与 vue instance 绑定。提供 vue instance 级别 container 的好处就是，在这个容器中的所有 bean 实例都可以在 vue instance 这个范围共享和消费数据。这种机制其实要比 composable 的耦合性低很多了

@Ma4cus 确实有几个 class 的实现效果不理想，所以 vue 官方不推荐。不理想的原因是他们把 class 用在了“与界面交互的架构”层面。而 cabloy-front 在“与界面交互的架构”层面仍然使用 vue setup 语法，在“与业务相关的架构”层面使用 class 和 ioc 。所以，与官方的说法并不相悖，只是站在不同的角度做的判断。

@coolcoffee 为什么不用 react ？参见我上面的回复。在面向大型的业务开发场景中，需要两个层面的架构设计。否则，代码多了一定会乱

@kneo 那么什么是反模式呢？为什么那么多人纠结用 ref 还是 reactive ，为什么有的地方推荐 ref 而不是 reactive ，为什么 ref.value 无法规避。为什么代码多了一样乱。

在面向大型的业务开发场景中，需要两个层面的架构设计：
1. 与界面交互的架构，这个使用 vue3 setup 来做
2. 与业务相关的架构，这个使用 ioc 容器来做。大量的工程实践证明，在业务层面，class 比 function 好用很多

@ixoy 这样就可以不再纠结使用 ref 还是 reactive ，不用担心失去响应式的烦恼，也不用再写大量 ref.value ，同时又能利用 vue3 的响应式

@FrankFang128 extends 某个基类，就可以通过`this.`直接使用大量常用的功能，减少 import 和 use 等导入代码。虽然使用了`this.`一样有类型校验，自动完成提示，也可以跟踪其源码出处

@linzhe141 ng 的 ioc 太繁琐了。cabloy-front 采用依赖注入和依赖查找相结合的方式，大量减少装饰器函数的使用，让代码更加简洁，再加上 vue3 的响应式和 tsx 的灵活性，整体效果比 ng 好太多。

@sjhhjx0122 思路是一致的。对于组件的类型导出，仍然延用 vue3 setup 的特性。依赖注入主要是面向业务层面。

@encro
在模块化架构中也可以实现你所说的“黑箱隔离”。其他模块需要什么 config 资源，在本模块通过 Service 服务包装提供即可

@encro 总感觉你要的是微服务架构，而不是模块化架构

@encro

如果只通过接口访问模块的资源，更好的方案应该是微服务
在一个大型项目中，模块的资源不只有 api 接口，config 和 error 资源也可以按照模块隔离，这样可以让与某个业务相关的资源代码充分自治

@encro 跨模块，不就是资源按模块隔离，然后再跨模块访问吗？

@encro 这句话不理解

@arfaWong 所以写这篇文章，必须得配动图，要不还以为又回到了 anyscript

如果上 NodeJS 工作流引擎，就用 CabloyJS