zhennann

@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 的特性。依赖注入主要是面向业务层面。