zhennann

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 ，是非常重要的里程碑。

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 该如何做呢？