VonaJS 提供了开箱即用的多租户系统。不仅支持共享模式（基于字段隔离）、也支持独立模式（基于数据库隔离），也支持混合模式（一部分租户使用共享模式，一部分租户使用独立模式）。参见： https://vona.js.org/zh/guide/env-config/instance/introduction.html

vonajs 的模块化体系全量采用 typescript+esm ，支持 node24+，对 dev/build/prod 都做了适配，可以算是目前最佳的实践了： https://github.com/vonajs/vona

花半天时间试一下 VonaJS ，提供了目前代码最直观、功能最全面的 ORM 框架

@FlashEcho 我简单解释一下，若有不妥之处，欢迎继续交流。Vona ORM 基于 Typescript 的类型体操，实现了非常便利直观的 ORM 体验。比如，可以基于静态关系或者动态关系，将任何多个 Entity 进行关联查询，并推断出多层次的实体，比如树形结构、主-明细结构、主-多级明细结构。而且，可以采用同样的机制动态推断与生成 DTO 。这些 DTO 可以直接用于 Swagger 文档的输出，以及 Reqeust 参数的校验。从实际操作上来说，就是只需定义 Entity ，和 Entity 之间的关系，剩下的都是动态推断与生成。

如果采用 spring boot ，就要一遍又一遍的写各种 DTO 、VO 之类的东东，而且里面的字段大多数都是重复的。

再举一个例子：在 Vona 中优先采用“依赖查找”，而不是“依赖注入”，代码更加简洁。比如，访问当前模块的 servcie ，只需`this.scope.service.student`，访问当前模块的 model ，只需`this.scope.model.student`，访问全局 service ，只需`this.bean.user`。诸如此类，由于 Typescript 的类型体操的加持，Vona 提供了大量简化代码的工程化设计，这些能力在 spring boot 中是很难做到的。

在开发后端 API 服务时，DTO 是进行参数验证、生成 Swagger 元数据的关键节点。如果不能像推断类型一样动态推断出 DTO ，那么，我们就仍然需要手工创建 DTO 。随着业务的增长，复杂的表间关系会让手工补充 DTO 的工作日益繁重。
而 Vona ORM 首创 DTO 动态推断与生成能力，解放我们的双手，显著提升生产力。甚至可以说，对于构建更加优雅的 Node.js 后端框架而言，能够动态推断与生成 DTO ，是非常重要的里程碑。

@XCFOX Vona ORM 是新出的框架，知道的人不多。不仅支持链式类型推断，也支持选项式类型推断，更支持 DTO 动态推断与生成

Nestjs 由于出现的比较早，其架构设计有点老了，建议试试全新设计的 Vonajs 。Vonajs 首创 DTO 动态推断和生成的能力，值得了解一下

为什么要排除 nest.js 呢？是否是因为 nest.js 提供的装饰器并不好用，声明一些 Openapi 相关的元信息太繁琐。
可以试试 VonaJS ，装饰器非常简洁，而且把参数验证与 Openapi 统一在一起了，不再是两张皮（不再写两遍）。同时 Openapi 中的描述信息还支持国际化能力。可以参见：[Entity]( https://vona.js.org/zh/guide/essentials/api/entity.html)和[Controller]( https://vona.js.org/zh/guide/essentials/api/controller.html)

@ByteCat drizzle-zod 貌似只能基于 table 模型生成 zod schema ，不支持基于 relations 生成 zod schema 。就比如此文中自动生成目录树的 DTO ，drizzle-zod 该如何做呢？

先插个眼，后续我来公布答案🐶

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

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