@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

使用 CabloyJS 全栈框架可以很好的兼容 pc 端和 mobile 端。
mobile 端与 pc 端的 UI 操控体验不一样，不是简单的 media query 就可以弥合差异的。CabloyJS 采用独创的 pc=mobile+pad 自适应布局机制，可以让 mobile 端用户体验接近移动端。
官方提供了一个一起点菜的在线演示，参见： https://cabloy.com/zh-cn/articles/demo-online2.html

参见：NodeJS 后端编译打包全攻略： https://cnodejs.org/topic/5dfa4f02ba8f6d46c4ede156