Vona ORM 文档终于肝完了，欢迎拍砖

我来拍砖了。

> Prisma 和 Drizzle 没有提供此能力
因为这是伪需求，java 写傻掉的 leader 才需要这种能力

而且你这 ORM 与 Prisma/Drizzle 等 ORM 完全不是一条路，连比较的意义都没有。
你的 ORM 依托于 Vona 框架本体，是一系列独家 API 和抽象的封装，并不是纯粹的框架无关 ORM 。

zod 的 schema 原本是一等公民，你在自己框架里是将其作为二等公民
findOne(@Arg.query('id') id: number) -> z.nmber()
findOne(@Arg.query() query: DtoStudentInfo) -> z.object()
多了一层被框架拘束的抽象与封装

这个所谓的动态推断与生成 DTO ，为什么要手动重复指定返回值类型。
```
@Api.body(v.array($Dto.get(() => ModelOrder, { include: { products: true } })))
async findAll() {
return this.scope.model.order.select({
include: {
products: true,
},
});
}
}
```
DRY (Don't Repeat Yourself)，你写的不是 TypeScript ，而是 Java ，或者说 SpringBoot 。
想做新的 web 框架，还是多看看 hono 和 elysia 吧，面向类型才是正确方向，面向对象已经是旧时代的残党了，nestjs 这条路已经走到头了，像 adonisjs 之类的也只能走全栈这条路另辟蹊径。

DTO 感觉没啥用，还不如直接写一份 request 、response 的 schema ，还灵活，相当于直接把 openapi 文档也给写了

@linecode #2 fastify/tRPC 以及继承他们思想的 elysia/hono 就是这样做的，schema=校验方式=类型=接口文档，typescript 世界不需要 DTO/VO/POJO/XXXO 。

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

你这一套 java 味太重了，那我为啥不用 sprinboot 和 mybatis

@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 中是很难做到的。

前端乐子人净整些烂活儿，看了看源码扎蛙味儿太重了，还有这无数的大括号令人想起回调地狱的绝望，多看看 efcore 和 jpa 里的 api 设计

看完感觉我像个小学生 ，不太清楚 Vona 的目标用户是谁。这和 Drizzle 给我的体验完全相反，Drizzle 的文档完全符合我的操作直觉。