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

[zhennann]

Vona ORM 是船新的 Node.js ORM 库。提供的多租户能力可以同时支持共享模式和独立模式。首创 DTO 动态推断与生成能力，解放我们的双手，显著提升生产力。为什么敢说是首创，因为 Prisma 和 Drizzle 没有提供此能力，Java 系亦如是。

Vona ORM 不仅提供基于静态关系的关联查询，还提供动态关系，从而适应大型业务系统所要求的灵活性和扩展性。

此框架所规划的能力还有很多，就不再赘述，以免占用大家宝贵时间。因为功能多，所以，花了大量时间终于把文档肝出来了。感兴趣的，可以观摩一下，欢迎拍砖。👏

文档地址： https://vona.js.org/zh/guide/techniques/orm/introduction.html

[Ketteiron]

我来拍砖了。

> 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 之类的也只能走全栈这条路另辟蹊径。

[linecode]

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

[Ketteiron]

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

[zhennann]

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

[FlashEcho]

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

[zhennann]

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

[leegradyllljjjj]

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

[C64NRD]

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

[riceball]

还需要再细拆分包，尤其是 AoP 这部分，和项目无关的可以独立出去。js npm 给我大开眼界的是哪怕一个函数也能独立成包。
Zod 应该只是可选项，对纯动态 json 无解，个人不喜欢，如果它只存在编译阶段就是个好东东，其实 ts 本身对运行时刻的动态类型也无解，我最多用来是在 vscode 中快速 hint 采用它的类型系统。
js 的优势是灵活和动态。Prisma 的规范我很喜欢，但是它居然不能动态创建数据集，这简直: https://github.com/prisma/prisma/issues/6442