Java 领域的ORM（Object-Relational Mapping）框架有很多，各家的性能和使用体验如何？本文将对比体验以下的Java ORM框架，包括Spring JDBC、Spring Data JPA + Hibernate、QueryDSL、jOOQ、GraphQL、MyBatis、MyBatis-dynamic-sql、MyBatis-plus、Fluent-mybatis、MyBatis-flex，以帮助开发者选型。
我们以diboot的操作日志表为基准，字段十几个，测试表中数据量约2万条。分别测试对比以下ORM框架：Spring JdbcTemplate、Spring JdbcClient、Spring data JPA、Mybatis、Mybatis-plus、Mybatis-flex。*（其他框架会在使用体验章节介绍） *
测试以下步骤：
- 循环执行 1000 次读LIKE 查询，重复多次
- 循环执行 1000 次写插入，重复多次测试
（注：因Mybatis-plus 和 Mybatis-flex 存在冲突无法共存，所以我们拆分为2个测试用例分别测试）
- Spring JdbcTemplate 是最接近原生JDBC的性能，以此为基准，Spring 最新的JdbcClient是在JdbcTemplate的基础上在对象映射上做了轻量封装，二者的读写性能都非常优秀。
- Mybatis 的读写性能仅次于Spring JdbcClient，非常优秀。
- Mybatis-plus 的读性能较好，在Mybatis的基础上损耗较小，优于Mybatis-flex（二者都是通过Lambda构建查询）。写性能上二者相差不大。
- JPA的读写性能不如Mybatis-plus（与Mybatis-flex混合测试还会导致无法写入）。
优点： 接近原生JDBC的性能
缺点： 仅提供了基础的对象映射转换处理，需要在Java中写大量的SQL语句，表多的话很难维护
示例：
优点： 有Spring体系的支持，关注对象模型不太关注SQL的简单场景用起来比较容易
缺点： 过度抽象，隐藏了SQL实现，背后的Hibernate驾驭起来也比较困难，复杂SQL条件构建与扩展都不方便
示例：
优点： 支持APT自动生成构建SQL所需的DSL类；可以作为JPA方案的补充，扩展完善其查询条件构建等能力
缺点： 国内比较小众，复杂SQL实现繁琐
示例：
优点： SQL构建方式相对优雅，写法接近原生SQL
缺点： 数据库支持少（开源版仅支持MySQL、PostgreSQL、SQLite等），国内比较小众
示例：
优点： 设计思路新颖
缺点： 只热过一阵子，把查询构建（业务逻辑）交给前端注定过于挑战开发者习惯，尤其是前后端分离场景下
优点： 性能优秀，使用简单，复杂SQL可以写在XML中方便统一维护，复杂项目更可控
缺点： 手写SQL过多，缺失通用Mapper、联表SQL手写复杂
优点： Mybatis官方出品的支持多表查询的动态SQL构建解决方案
缺点： 缺少APT自动生成方案，手写代码过多，使用起来缺失一点优雅
优点： Mybatis的扩展框架，性能较好，支持通用Mapper等，单表CRUD、查询条件构建写起来比较优雅
缺点： 缺少联表查询方案（可使用 Diboot core 内核实现）
优点： 借鉴了jOOQ的实现思路
缺点： 已停更
优点： Mybatis的扩展框架，支持通用Mapper，支持APT生成DSL辅助类，支持多表，动态SQL构建也相对优雅。像是借鉴了众多ORM的优势实现的一个既要又要的解决方案。
缺点： 查询性能还有优化空间（v1.8.x版本），稳定性还有待验证
Java ORM虽然很多，综合下来目前主流的还是JPA（Hibernate）和Mybatis两大阵营。
- Mybatis拥有良好的性能和应对复杂场景的能力，国内使用更广泛是有理由的，个人建议首选站队Mybatis，除非你的项目非常简单。
- 针对Mybatis的不足，如果你追求稳健，可以使用 MyBatis-plus + Diboot 。如果你的开发场景能够接受尝鲜，可以使用 Mybatis-flex（Diboot 后期也可能会适配）。
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/10026.html