@tikazyq 已经将 mother 相关的术语改为 controller 。多谢建议🙏

@tianzi123 如果代码都在 sfc 中，使用这些语法糖确实舒服。但是代码一多就乱；如果想拆分多个 hook 出去，这些语法糖的使用可能就不太方便了。Cabloy-Front 采用 ioc 容器，从一开始就把结构搭好了，不论代码再多也不会乱，而且可以平滑的扩张。

@tianzi123 我也不喜欢 vue2.6 的装饰器写法。但是 Cabloy-Front 采取的策略完全不同。之前的装饰器写法不好用，是因为在用 class 定义 Vue 组件。实践证明，用函数式定义 Vue 组件最方便。所以，Cabloy-Front 仍然在视图层使用 setup 语法糖来定义组件（包括 Props 和 Emits ），而在业务层引入 ioc 容器和 class 。同时又采用了依赖注入与依赖查找相结合的策略，大量减少装饰器函数的使用，让代码更简洁优雅。这是 codesandbox 的在线演示，可以看一下： https://codesandbox.io/p/github/zhennann/cabloy-front-demo-codesandbox2/main?checkout=true&embed=1&file=%2Fsrc%2Fsuite%2Fa-demo%2Fmodules%2Fa-demo%2Fsrc%2Fpage%2Fcounter%2Fcontroller.ts

@wuzzispacelake 你说的情况我了解。Vue team 不认可 class api 的理由我也看到了。他们的理由是使用 class 定义 vue 组件并不方便，代码冗余，性价比不高。这点我也认同。社区有好几款基于 class 来定义 vue 组件的方案，效果都不是很理想。这就说明了一个道理：Class 不应该用在视图层，而是要用到业务层。所以，Cabloy-Front 仍然在视图层使用 setup 语法糖来定义组件（包括 Props 和 Emits ），而在业务层引入 ioc 容器和 class 。这样，可以充分利用二者的优势，让整个代码更加简洁优雅。因为使用了 class 之后，再也不需要使用 ref/reactive 了，也不需要 ref.value 了。可以参考这篇文章：为什么需要 Vue3+IOC： https://front.cabloy.com/zh/guide/start/why.html

@sunorg 这种情况我也遇到过。随机性比较强，比较魔幻。

@IvanLi127 你可以对比一下 Angular 和 Cabloy-Front 的代码风格，看看是不是这么回事。这里有一些视频，可以作为参考： https://front.cabloy.com/zh/guide/resources/videos.html

@wuzzispacelake Cabloy-Front 采用的 class 机制与 Vue Class Component 有本质区别。Vue Class Component 不好用，是因为想用 class 解决 Vue 组件的定义问题。而 Cabloy-Front 仍然采用 Vue3 setup 语法糖来定义组件（如组件的 Props 和 Emits ），仅在业务层面引入 ioc 容器和 class 。这样，就结合了二者的优点，让代码更加简洁优雅。在 ioc+class+ts 的语境下，this 不仅可以清晰定位代码来源，还能更加快捷的访问系统能力。this 的弊端，仅仅是针对 mixins 和 options api 而言。
rxjs 是 angular 中的用法，Cabloy-Front 中并没有采用。
Cabloy-Front 提供了两类 ioc 容器：一类是全局 ioc 容器，可以实现 pinia 的能力。另一类是组件实例 ioc 容器，该容器与 Vue 组件实例绑定，在这个容器中的所有 Class 实例都可以在组件实例范围之内共享数据和逻辑。

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