泼个冷水

粗略扫了一眼文档，感觉没有比 Ktorm / Exposed 这类 ORM 更强，更不用说和 Slick / Quill 这种真强类型且类型安全的 FRM 了。

甚至在 TS 上玩类型体操的 Prisma 都能做到很大程度的强类型安全，我觉得以目前的理论成分看，”革命性”还有些距离......

预测，不是结论：同时对打两个东西的缺点，往往会变成同时去掉两个框架的优点并集中它们的缺点。

@nothingistrue 同意，用过 beetlsql 也是各种方式都可以，但实际问题很多

大致看了一下，这东西还是可以用的。理念上有两部分，一， 从 O 半到 M：隐藏 SQL ； O 端托管状态；没有 O-M 强关联。 二，对象模型是参考 JSON 或者 树的动态对象。

这里的重点还是这个对象模型，如果业务上的数据模型就是这种树模型的话，它这个用起来倒是很不错。但是很不幸的是，Java 体系面向的业务，有心的话是领域模型或 ER 模型，无心的话直接用关系模型（就算没有数据模型的纯靠界面原型或者扣扣相传的小作坊，背后也是不知不觉用着关系数据模型），在这些模型上它这个框架基本用不了，如果硬要用，那就真成了集 JPA 和 Mybatis 的缺点与一身。

@nothingistrue 你的理解的大方向是对的，get 到重点了。

至于你的担忧，不知道 Jimmer 设计如何，不确定最终达到的的效果究竟是是集两个派别的优点于一身还是集两派别缺点于一身，欢迎加入 Jimmer 群探讨。

Jimmer 群中有很多小伙伴，有些已经生产环境中上线了 Jimmer ，有些开发了配套的工具（因为我表示只想做框架本身，不想开发配套工具），但他们有一个共同点，实际项目中使用后再也不愿回去了，无论是传统 ORM 还是 DTO 映射派。他们年轻、热情、认真、阳光，是一个很好的交流环境。

@nothingistrue 这个动态树模型，针对忠于原始数据模型的 OLTP 功能，并非经过分析计算的 OLAP 功能（目前支持简单的计算属性，单还不支持 OLAP 数据库那种强烈分析能力，未来把复杂的计算属性映射到 OLAP 系统是未来的大规划之一）。这种返回业务分析指标的功能，和原始数据结构没什么关系，应该定义 DTO ，这种 DTO 不是 Jimmer 的反对对象。

Jimmer 彻底改变了开发人员看待关系型数据库的视角

针对特定业务场景，允许开发人员从全局的对象关系模型中，勾勒出当前业务场景关心的数据边界，即，选取一个局部的对象关系模型。然后，把这个局部数据结构作为一个整体，进行
a. 查询
b. 修改
c. 缓存

此视角的变化，可以让所有行业复杂业务的开发效率质变，事半功倍。

这个视角变化，是 Jimmer 的本质特征。

如果把用户随意截取的这个局部数据结构视作一个文档，那么 Jimmer 提供的就是文档数据库操作接口。然而，这比真正的文档数据库还好，因为，在文档数据库中，各文档的结构在设计数据库存储时就已经定死，完全固化且彼此孤立；而在 Jimmer 中，各文档边界是开发人员为每个业务场景“临时起意”而勾勒，变化无穷且可以彼此重叠。

@lmshl 俄联储首席技术专家讲 Jimmer, https://www.bilibili.com/video/BV1Cp13YdEQ3

@lmshl 为了 Java 和 Kotlin 创建的 ORM ，搬 scala/typescript 出来怼几个意思啊？折不胡搅蛮缠吗？

完全无法看清一个革命性框架框架的和设计，只能在特性更多的编程语言中寻找嗨点，你的层次真的是堪忧啊。再者，scala 是你发明的还是你创造啊？

我唯一的错误，是在颠覆行业的方式不是以硅谷巨头的身份，而是以个人身份。为此，辞去工作并用爱点发现，还被各种小白陪，一直默默忍受，真的无语了。

我完全不在乎普通程序员会如何看待，我只在乎如何征服行业顶尖专家：俄联储首席技术专家讲 Jimmer, https://www.bilibili.com/video/BV1Cp13YdEQ3

在你认知层次实现跃迁之前，请对陌生的东西保持一份谨慎和客观，因为你无法判断对方是忽悠人的二逼，还是有真才实学完全不屑于炒作和骗人的那种。