@yuankui 其实跟标题说的一样，Java 也不能很好的支持自动推断生成 DTO ，所以，开发工作繁重。对于标准的后端 API 而言，DTO 甚至可以说是必须的。因为有了 DTO ，我们就可以支持传入参数的校验，也可以支持 Swagger 元数据的生成。

1. Vona ORM 支持“临时或一次性的连表查询”
2. Vona ORM 支持“自动推断生成 DTO”。Prisma 不能优雅的支持 DTO 。如果不能像推断类型一样自动推断出 DTO ，那么，我们就仍然需要手工创建 DTO 。随着业务的增长，复杂的表间关系会让手工补充 DTO 的工作日益繁重。而 Vona ORM 就解决了这个痛点问题： https://ex.noerr.eu.org/t/1150216

@PHSix 如果采用 vite 默认的拆包配置，分成两个 chunk ，自然不会导致互相引用。但是，这会导致大量小文件的产生。为了避免这种碎片化，就需要通过 rollupOptions.output.manualChunks 定制拆包策略，比如把某些文件合成一个 chunk 。在这种情况下，如果配置不当，就会导致循环引用，参见图示的范例。

建议使用[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