建议使用[Zova]( https://github.com/cabloy/zova)框架。Zova 提供的模块化机制，让业务拆分更容易，便于开发高内聚低耦合的系统。Zova 框架同时结合了 Vue/React/Angular 的优点，并规避他们的缺点，让我们的开发体验更加优雅，并且显著减轻心智负担。

1. Vue：Zova 仍然使用 Vue3 便利的响应式系统，但是定义响应式变量就像原生变量一样，不需要使用 ref/reactive ，自然也不需要 ref.value 。
2. React：Zova 在一个 Render Class 中通过 tsx 语法来书写渲染逻辑，不仅可以与 TS 类型系统完美契合，也可以支持渲染代码的拆分，即便是面对复杂业务也可以保持代码的舒展与优雅。在 Zova 中没有类似 React 的众多 hook api ，大量减轻心智负担。
3. Angular：在实际开发当中，会遇到三个场景的状态共享：组件内部状态共享、组件之间状态共享、全局状态共享。在传统的 Vue3 当中，分别采用不同的机制来实现，而在 Zova 中只需要采用统一的 IOC 容器机制即可。Zova 提供的 IOC 容器，摒弃了 Angular 繁琐的设计，概念更加清晰，功能更加强大。

@Greendays 可以试一下基于 Vue3 的 Zova 框架，提供的 IOC 容器概念更加简洁，更容易上手，再配合 Vue3 的响应式系统，开发效率非常高： https://zova.js.org/zh/guide/start/introduction.html

选择这么困难，为何不换个角度呢？可否有一个框架可以结合 Vue/React/Angular 的优点，同时规避他们的缺点，让我们的开发体验更加优雅，减轻心智负担。这就是基于 Vue3 开发的 Zova 框架： https://zova.js.org/zh/guide/start/introduction.html
1. Vue：Zova 仍然使用 Vue3 便利的响应式系统，但是定义响应式变量就像原生变量一样，不需要使用 ref/reactive ，自然也不需要 ref.value
2. React：Zova 在一个 Render Class 中通过 tsx 语法来书写渲染逻辑，不仅可以与 TS 类型系统完美契合，也可以支持渲染代码的拆分，即便是面对复杂业务也可以保持代码的舒展与优雅。在 Zova 中没有类似 React 的众多 hook api ，大量减轻心智负担
3. Angular：在实际开发当中，会遇到三个场景的状态共享：组件内部状态共享、组件之间状态共享、全局状态共享。在传统的 Vue3 当中，分别采用不同的机制来实现，而在 Zova 中只需要采用统一的 IOC 容器机制即可。Zova 提供的 IOC 容器，摒弃了 Angular 繁琐的设计，概念更加清晰，功能更加强大

@qrobot 小型项目与大型项目的诉求不同，对框架设计的要求也就不同。对于大型项目而言，通过一个精炼的 runtime 把常用的开发范式内聚成一个核心，不仅有利于规范团队开发，也可以大量减少重复性代码，让精力更加聚焦于业务领域本身。我这里可以举两个例子：
第一个例子：在实际开发当中，会遇到三个场景的状态共享：组件内部状态共享、组件之间状态共享、全局状态共享。在传统的 Vue3 当中，分别采用不同的机制来实现，而在 Zova 中只需要采用统一的 IOC 容器机制即可。参见：[简洁而强大的 IOC 容器]( https://zova.js.org/zh/guide/essentials/ioc/introduction.html)
第二个例子：在实际开发当中，会遇到四种全局状态数据：异步数据（一般来自服务端）、同步数据。同步数据又分为三种：localstorage 、cookie 、内存。在传统的 Vue3 当中，分别采用不同的机制来处理这些状态数据，那么可否采用统一的机制进行管理呢？此外，对于大型项目，用户需要长时间进行界面交互的场景，如果存在过多的全局状态数据，就会导致内存占用过多，有什么破解之道呢？ Zova 提供的 Model 机制可以用更优雅、更简洁的代码解决以上问题，参见：[Model: 统一数据源]( https://zova.js.org/zh/guide/techniques/model/introduction.html)
此外，经过近半年的进化，Zova 的整体架构得到进一步精简，并且提供了 VSCode 插件，通过右键菜单提供大量工具，显著提升开发体验，包括四大类能力：Create/Init/Refactor/Tools 。若有空可以一试。

@gogozs Zova 与 Java 的代码风格有显著的不同，体现在以下两个方面：
1. 更少的装饰器函数：Zova 采用依赖注入与依赖查找相结合的策略，优先使用依赖查找，从而大量减少装饰器函数的使用
2. 更少的类型标注：Zova 优先使用依赖查找可以达到化类型于无形的开发体验，也就是不需要标注类型就可以享受到类型编程的诸多好处，从而让我们的代码始终保持简洁和优雅，进而显著提升开发效率，保证代码质量

@unco020511 请参见这篇文档：为什么需要 Vue3+IOC： https://zova.js.org/zh/guide/start/why.html

@qrobot ts 与 java 装饰器的不同：ts 装饰器不仅仅是装饰，而且可以在代码初始化时，执行一段初始化逻辑，从而主动在系统中注册资源。而 java 装饰器没有这个主动初始化的阶段，因此需要扫描

1. Zova 提供了模块化体系，以模块为单位实现独立的打包，从而也是以模块为单位实现异步加载。这确实存在 tree shaking 失效的问题，但是可以避免打包产物碎片化严重的问题，同时也能避免初始包过大的问题。对于小项目，tree shaking 可能优先于碎片化，对于中大项目，碎片化和初始包大小可能优先于 tree shaking 。这是一个 trade-off 问题
2. 多一个 runtime 开销是否值得，也和项目的规模有关
3. 调试是否复杂跟代码结构有关。Zova 提供了更多的代码规范，代码更加清晰，或许更容易调试一些。反之，原始的 Vue3 并没有对业务架构做出更多的约定，也没有提供现成的最佳实践，代码风格反而难以统一。

@ZGame 为什么 class 契合度太低了？可否再详细说说？

@qrobot 前端是异步体系，许多模块都是按需异步加载的，采用 componentScan 不能解决所有问题。在 Zova 中，装饰过的 class 在初始化时就自动注册到系统中了，不需要扫描

@wuyiccc 在 Zova 中，装饰过的 class 在初始化时就自动注册到系统中了，不需要扫描

@lisongeee 不理解你要表达的是什么

@zhongs Cabloy-Front 提供了许多 cli 命令行工具，帮助我们搭建代码骨架，所以有些代码不需要我们写，只需要写业务代码即可。可以看一下 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

@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 实例都可以在组件实例范围之内共享数据和逻辑。