Java/Kotlin双语革命性ORM框架Jimmer（一）——介绍与简单使用

IManiy

于 2025-02-06 17:29:46 发布

阅读量1.8k

点赞数 15

分类专栏： java及javaweb 文章标签： java kotlin 开发语言

本文链接：https://blog.csdn.net/IManiy/article/details/145477894

版权

概览

Jimmer是一个Java/Kotlin双语框架

包含一个革命性的ORM
以此ORM为基础打造了一套综合性方案解决方案，包括
- DTO语言
- 更全面更强大的缓存机制，以及高度自动化的缓存一致性
- 更强大客户端文档和代码生成能力，包括Jimmer独创的远程异常
- 快速创建GraphQL服务
- 跨越微服务的远程实体关联

ORM部分

当前技术生态下，访问关系型数据库技术体系存在很大缺陷，请看下图。
在这里插入图片描述

1. 以JPA为代表的静态语言ORM

优点

便捷，代码安全(本身基于强类型语言，大部分代码是安全的。如果结合QueryDSL使用，则可以保证所有代码都是安全的)

缺点

缺乏灵活性

即使JPA从2.1开始支持EntityGraph，控制被查询数据格式的灵活性仍然非常有限。该方案粒度仍然太粗，控制能力远没GraphQL这类技术的细腻。

保存对象时，细节行为受普通属性的insertable、updateable和关联属性的cascade配置的控制，这类配置在实体类型中被硬编码固化，被保存的数据结构的格式是固定的，没有灵活性。

如果要发挥ORM的优势，就必须查询对象的大部分非关联属性 (少数@Basic(fetch = FetchType.Lazy)属性除外，它们多为lob设计)；如果只想查询一部分属性，就必须放弃对象查询，转而使用这些属性的多列查询，丧失ORM本该有的便捷性和核心价值。

3. 以为ActiveRecord (Ruby) 为代表的动态语言ORM

优点

基于动态语言的ORM，只需将动态语言对象结构的灵活性和ORM的实现结合起来，就能兼顾便捷和灵活。

缺点

动态语言虽然既便捷又灵活，但是代码缺乏可维护性且不利于多人协同开发是众所周知的缺点。

现代软件往往是复杂的，需要团队协作来完成，是否利于团队成员之间协同，远比个人对编程的认知重要。

这里，不想过多地讨论动静之争，但是有一点需要指出：既然选择了静态语言Java/Kotlin，就应该以静态语言的方式使用它，而不能使用以jFinal为代表的将静态语言当成动态语言用的方案，更不能在应用中频繁地使用java.util.Map来代替数据对象。这类做法违背了选择Java/Kotlin的初衷，如果一定要怎么做，为什么不直接选动态语言呢？

4. 以MyBatis为代表的轻量级SQL Builder/Mapper

优点

直接编写SQL，随意且灵活；本身是强类型框架，具有代码安全性 (MyBatis生态也有强类型SQL DSL扩展，可以解决原生SQL字符串导致的代码不安全问题)

缺点

便捷性的严重缺失，重复劳动量极大。

MyBatis没有统一实体的概念，而是面对具体业务场景DTO，实现ResultSet和这些DTO的映射。由于业务场景多，各DTO类型之间相似却不同，冗余度很高，导致重复劳动量极高。

除了以孤单对象为载体的CRUD外，对多个对象彼此关联而成的复杂数据结构的支持较弱，缺乏必要抽象，导致太多繁重的低级任务被推卸给开发人员 (不少开发人员长期被这类繁重的任务所累，但自己一直没察觉)。

原生SQL真的是最好方案吗？
这个派别最引以为豪的观点是：“直接书写SQL会带来更直接的控制力，这种直接控制力优于任何ORM”。在这个领域长期的技术停滞中，不少开发人员对此深信不疑。

根本原因

上文中，我们阐述了关系型数据库领域的三种常见方案，但无论如何选择，我们都无法兼顾便捷性、灵活性和代码安全性。为什么会导致这样呢？

就JVM生态而言，POJO是导致这个问题的根本原因。

POJO*(也可以叫结构体)*缺乏必要的灵活性和表达力，却几乎被所有的JVM框架作为数据模型和核心，严重限制了JVM生态的技术创新。

因此，在Jimmer中，ORM实体对象并非POJO。而是另外一种独特的万能数据对象*(后文会介绍)*，这种独特的实体对象撑起了Jimmer所有上层重大的变革，是整个框架的基石。

事实上，Jimmer实体对象不仅可以应用在ORM领域，它几乎可以用在任何以结构化数据维护为目的的场景，并提升各种技术栈的表达力。

目前，Jimmer实体仅在关系型数据库访问领域发挥出作用，只是因为精力不够所致。

完整的功能

在本文开头我们提到了，革命性的ORM只是Jimmer的一部分，Jimmer实际的能力范围早已超越了一个ORM。

现在，我们给出Jimmer的功能示意图，并逐个讲解
在这里插入图片描述

Business Model

在信息类系统中，存在两种对象。

实体：实体对象是全局统一的，对象之间的存在丰富彼此关联。

实体对象往往和数据库非常接近，具备极高的稳定性。

DTO：针对特定业务的输入/输出对象，通常是从全局实体关系网上撕下来的一个局部碎片，该碎片的大小和形状非常灵活。

DTO类型数量庞大，每一个业务接口对DTO对象的格式都有独特的需求，彼此可能相似但又不同，具备明显的。而且易受到需求变化的影响，不稳定。

Entity类型是全局统一数据存储模型，不易被需求变更影响，相对稳定，被视为高价值类型。

DTO类型作为每个业务输入/输出，相对随意，容易因需求变动而不稳定，被视为低价值类型。

Jimmer主张开发人员把精力集中在高价值的实体模式的设计上；对于低价值的DTO类型，有的时候并不需要，有的时候需要。
即使需要，也可以用极其廉价的方式自动生成。因此，基于Jimmer构建的项目具备优秀的抗需求变动的能力。