JPA 为何如此难用，是我姿势不对吗

[XiLemon]

RT，明天就过年了，我还在写 JPA 的东西，我快吐了。。。

声明：因为是第一次用，不熟悉，另外，个人认为是本人不理解 JPA 的设计思想，所以用起来很不顺手。

槽点：

1. 多个条件，组合查询，当有些条件没有传参的时候怎么处理
   • 代码层面处理：用 specification 来处理，写起来好啰嗦，过于麻烦
   • @Query 注解，写原生 SQL 也挺恶心的
2. 指定 update 条件
   应该不支持吧，只能用 @Query 注解写原生的 SQL，一旦字段比较多，而且部分可能为空的情况，写起来也是噩梦
3. 多表关联查询
   JPA 不推荐多表关联查询？用起来也不够方便。

我是在用 MyBatis 的思路来用 JPA，完全不对路子。MyBaits 很灵活，在使用 JPA 的时候，感觉到处都是限制和不便。比如要用乐观锁，JPA 虽然有 @Version 注解处理，但是只能在 save 的时候才能用到。

用 MyBatis 感觉是在呼吸自由的新鲜空气，用 JPA 感觉是在地下室。。。

那么用 JPA 的朋友，是真的不需要灵活性，从业务设计上就完全解决了这些情况么。

本帖带有强烈的个人主观印象，用词如有冒犯到 JPA 用户，请强势打脸，教我做人！

打工人，打工魂，打工人是人下人 o(╥﹏╥)o

提前祝大家新年快乐！

[lewis89]

ORM 就是 深陷泥潭的越南战场，任何试图从 SQL 到 Modeling 找一层简易或者容易理解的抽象 都是在做无用功

[lewis89]

理想的弗洛伊曼体系是 不存在硬盘这种低速随机读写存储社保..

[sheeta]

用过最舒服的还是 laravel 的 orm

[frandy]

1.1 、复杂条件语句可以试试引入 querydsl
1.2 、简单的一般直接 findby 自动生成，不需要设计到原生 sql
2.1 、不知道支不支持，生产中我们是直接从数据库中获取对象，然后赋值更新。
3.1 、杜绝表关联，两个表如果有关联的在业务层面拼接后返回给前端。
JPA 在 sql 优化上很麻烦，比如一条复杂语句，dba 检测到某个语句性能有问题，你排查起来不能很直观的根据原生 SQL 去找。优点也是这个，你没必要关注原生 SQL，不懂数据库的都能写。
目前新的项目，如果规模很大的，转到 MyBatis Plus 了，小规模的项目用 JPA 真的爽。

[XiLemon]

@lewis89 #1 此刻只想要灵活了
@sheeta #3 没写过 PHP 额
@frandy #4 2.1 每次都要 select 一遍，然后再 update 么，这也太麻烦了。。。 还是 MyBatis 舒服

[frandy]

@XiLemon #5 是的，原生只要一句话，基于 orm 的话，就得两句话了。

[Vedar]

主要是 java dsl 能力太弱了 jpa 这搞法真的是双重打击 将 java 的弱点发挥到极致了 还自以为很优雅

[Leviathann]

我们的后台管理+内部 crm 系统用的 jpa
单表简单查询用 findby
联表或者 n 多条件筛选可传可不传的都用自己封装的 query builder

[Leviathann]

update 的话都是用 java 代码做的
先 find 再 save

[XiLemon]

@Vedar 个人认为难用极了（现场学习 DSL： https://www.jetbrains.com/zh-cn/mps/concepts/domain-specific-languages/

[XiLemon]

@Leviathann 单表的 CRUD，感觉还行，但是这一点 MyBatis 也能做到。但是多表关联查询以及写原生的内容 SQL JPA 的支持可太弱了

比如有些条件更新：update tb set a ..., status = ? where id = ? and status = ? 这种 update 语句，JPA 就无能为力了

[lawler]

mybaits 是 java 和 sql 隔离层，你清楚的知道，你在写 java 和 sql 。
JPA 是整体，忘记你在操作数据库，然后用面向对象方式对属性写逻辑描述。

1，多条件组合查询。 [不需要 sql]
findByStatusAndUpdateTimeBefore(String status, Date date);
findFirstByStatusAndIdNotInOrderByUpdateTimeDesc(String status, List<String> ids);
findFirstByStatusOrderByUpdateTimeDesc(String status);

2，指定条件删除 [更新同理，不需要 sql]
removeByCreateTimeBefore(Date updateTime);
removeByNamespace(String namespace);

3，多表关联查询。 [注解和 sql 条件]
@OneToMany(fetch=FetchType.LAZY, mappedBy="user")
@BatchSize(size=10)
@Where(clause="DEL_FLAG=1")
@OrderBy(clause="CREATED_DATE asc")

[Kirsk]

spring jpa 是根据 jpa 规范来实现的 本来思路就是不一样一个以对象建模 一个以数据库 SQL 用 mybatis 连表也强不到哪去 都一样是写 SQL

[FightForFreedom]

jpa 的话 update 可以的吧，虽然要加个 @Modifying 注解

[XiLemon]

@lawler #12 1. 用 findXxx 的方式查询的都是固定的。如果说有多个查询条件：a & b & c，当 b 不存在是，去掉它，用 a & c 这两个条件来查询。
2. remove 是物理删除么？通常业务做法是逻辑删除。update 同理指的是有这儿 updatXxxx 的接口方法么，IDEA 上没有这种提示额，能具体说一下嘛
3. 在 Entity 上写注解来关联查询，很麻烦呀。MyBatis 也支持在 Mapper.xml 中配置 Collection 来进行关联查询。这两种方式都很麻烦，而且比较固定，不够灵活。但是 MyBatis 能用原生 SQL 解决掉这些问题

整体上来进，JPA 的原则是不用 SQL，只操作实体类。可我没遇见过能完全不依赖 SQL 的场景，所以在原生 SQL 的支持上，JPA 的体验很烂。MyBatis 属于半自动化的 ORM 框架，在单表查询上没有比 JPA 繁琐多少，在灵活性上远胜 JPA 。MyBatis Plus 又弥补了单表查询不在便捷的缺点。

[XiLemon]

@lawler #12 @Where(clause="DEL_FLAG=1") 这个应该是逻辑删除的用法了
@Kirsk #13 我觉得 MyBatis 让我可以选，JPA 只能用它那一套了。两个框架（ JPA 是规范，暂时代表实现 JPA 规范的框架）思路确实不一样。我比较好奇的时候，您在实际业务场景中，不会依赖原生 SQL 么？
@FightForFreedom #14 嗯，这个我知道，就是不够灵活。

[lawler]

@XiLemon #15
1. 使用 Specification 进行查询条件封装。和 mybaits 写 xml 一样。
我接触的 jpa 项目都不允许都这么复杂的设计，不利于维护，如果需要会进行评估。

2. 更新是 save 方法，自己操作对象进行更新。

3.无解。 如果不是报表系统，一般也不会进行多表关联查询的。极端需要性能的，干嘛不直接上 jdbc 呢。

[cgpiao]

ruby active record
业务类开发用 java 有些遭罪，用脚本语言吧。

[XiLemon]

@lawler #17 目前是用 Specification 来做的，感觉这个用起来足够啰嗦了，准备春节的时候看下 QueryDSL 会不会简洁一点。其实逻辑不算很复杂，没有超过 3 张表的关联，一般关联查询也就是两张表了。如果用 MyBatis 的话，能很快做完需求。

[XiLemon]

@cgpiao #18 -_-|| 打工人，公司项目用啥，我用啥呀。而且是在已有项目做的需求，没得选额，不然 MyBaits 一把梭，就不会有这个帖子了。

[Kirsk]

@XiLemon 不会啊 我设计表原则都是对象加关系表 复杂场景可以多实体映射一张表 避免不需要的字段

[huang7230468]

个人见解：
1. JPA （ Java Persistence API ）是外国定义的一套数据持久化规范的 API，像我们现在用的 Spring-Data-JPA 底层就是 JPA，但 Spring-Data-Mongo 就没有；而 Mybatis 是国人写过，是一套非常灵活的 ORM 框架；
2. JPA 是支持单表或者多表的，但多表是需要自己写 Native SQL ；而 JPA 其实推崇使用单表的，有点像国内现在推崇尽量减少 join 关键字，从减少数据库的压力（当然这里也是看业务场景，不是一味的盲从）；
3.JPA 是从面向对象的角度设计的，减少 SQL 的硬编码，以减少后期的更换数据库的迁移成本；
4.JpaSpecification 的写法复杂度，其实是可以容忍的，因为稍微花点的时间，你会爱上他；

对于 JPA 需要改变以往的从数据库从发的设计，学会从业务建模的角度开始，可能会有更好的思路。目前我们已经用了几年，只会感觉越来越好用，越来越简单。

[BBCCBB]

@huang7230468 指正一下, mybatis 不是国人写的 🐶

[winglight2016]

不讲需求场景，没法比较吧。JPA 应该是偏向 OOP 的，一般的 CRUD 业务可以很方便地实现，从设计角度看，对象建模比数据库建模更容易表达业务需求，也不容易出错。mybatis 是面向 SQL 的，需要程序员非常了解表结构才能开发，而且需要重新做业务到 SQL 的映射，这个过程容易产生理解偏差。以上就是 JPA 的优势。

至于 JPA 在某些场景下的不便，lz 的说法看起来有一半是不熟悉这种 ORM 的思路导致的，另外一半，包括批量更新和复杂查询，这两个场景的确不适合使用 JPA 实现，个人会考虑使用异步任务和搜索引擎 /动态视图这样的方法来实现。在我看来，mybatis 和原生 sql 没有太大区别（设计角度看），所以仅仅是方便写代码的优势并不会让我选择它。

[jaynos]

没人觉得 mybatis 也很麻烦啰嗦么，xml 配置没有类型安全（指编译时检查）我就觉得很淦。

在后台一些场景（如一个商品列表，需要展示商品信息，店铺信息，收藏人数）在动态查询的时候 Specification 和 mybatis plus 都是啰啰嗦嗦几十行，不知道大家在这种场景下是怎么干的。。。

[chocotan]

我自己的项目用 jpa，公司的项目用 mybatis
用 mybatis 的思维去写 jpa 肯定是会遇到各种问题的

[XiLemon]

@huang7230468 #22 JpaSpecification 我真的爱不上啊，MyBatis Plus 是国产的，MyBatis 不是。另外，迁移数据库，以我有限的职业生涯来说，不知道会不会遇到，至少目前没有。我理解到了要迁移数据库的层面，可能重新写业务是更好的方式吧。
@winglight2016 #24 确实不熟悉，也不太理解这种思想。需要深入学习一下，请问有合适的资料可以推荐一下么
@jaynos #25 我觉得也还行啊，稍微有点啰嗦。
@chocotan #26 我也认为是思路有问题，但是实际上确实要用到原生 SQL 的功能。

问题来了，怎么掌握 JPA 的这种设计思想呢？

[iamppz]

目前是 JPA 、原生 SQL 混合使用，动态的部分交给原生 SQL 去处理，领域逻辑相关的部分交给 JPA 处理，代价就是需要花额外的时间去做兼容。其实 MyBatis 也有 MyBatis 的问题，不是有句老话叫「没有银弹」，没有任何一个框架能解决所有的问题。

[wc951]

因为你依然处在面向关系型数据库编程的思维方式，尝试阅读有关 DDD 、CQRS 之类的概念会有些帮助，还要考虑你的场景到底是属于 olap 还是 oltp

[idoggy]

mybatis 我现在也不手写 sql 了，需要手写的都能用 dsl 实现，实现不了硬要手写的就加开评审会好好梳理下逻辑

[aguesuka]

本质是 java 的类型系统无法为 sql 做静态检查。大家可以了解一下"依赖类型"这个概念。
等 java30 支持"dependent type"以后就会非常愉快了。

学术界已经有解决方案了

https://homotopytypetheory.org/2016/09/26/hottsql-proving-query-rewrites-with-univalent-sql-semantics/

[hantsy]

最好是找一本 JPA 方面的书籍系统的学习一下 JPA，推荐 Gaving King 的 Manning 出版的 Java Persistence with Hibernate， 或者 Apress 出版的 Pro JPA 2 。

想通过简单的 API 认识入门，用好 JPA 的可能性不大。早在 15 年前，国内很多使用 Spring，基本都是会配合使用 Hibernate，那时 Hibernate 官方文档是不可多得资料。现在能够静下心来看几百页文档（或者书籍）的年轻程序员太少。我常常看到一些国内的技术博客，看到别人某篇文章，自己依葫芦画飘的写一个 Hello World 程序就得出结论，Hibernate/JPA 这不行那不行。看到 JSF 的时候， 在某些人的眼里就是 JSP 一样，只是换换 tag 而已。

我面过很多自称非常熟悉的 Hibernate/JPA 的程序 ，连最基本的一级缓存（或者 Hibernate Session，或者 Persistence Context ）中几种对象的状态（这是基础中的基础）的转换都说不上来。一个 Hibernate LazyInitialzationException 和 N+1 查询都是可以检测你是不是真正用到 Hibernate/JPA 。自称用过 JSF 的居然连基础的 request Lifecycle 都说不上来（更有甚者，没听说过）。

JPA 作为一套规范，完全使用 OOP 方式解决 Java Persistence 问题，使用 JPA 时完全可以忘记数据库的存在。最初是很好的解决了 ORM，而且仅针对 RDBMS， 但是随着 NoSQL 的流行，Hibernate OGM （使用 JPA 操作 NoSQL ）新项目已经支持常见的 NoSQL 。可惜 NoSQL 天然操作上不如关系数据数丰富，有些 NoSQL 也宣称支持 SQL （也只是部分支持，使用上很多限制，比如 Cassandra ）。

Eclipse 下 JNoSQL 项目会形成一套规范 API 操作 NoSQL，与 Jdbc 和 JPA 相似，分为高低两级 API，其高级的 API 与 JPA 极为类似，可能集成到下一代的 Java EE/Jakarta EE 10 标准中去。

[hantsy]

JPA Provider 目前几种：Hibernate （非常活跃），EclipseLinks 比较活跃，OpenJPA 不那活跃了。DataNucleus 最初是 JDO 标准的参考实现，后来扩展到支持一系列的标准，包括了 JPA 。 一般项目很少用，这个最初 Google 云上内置支持。

由于 Spring Boot 默认使用了 Hibernate 作为 JPA 实现，所以很多同学在不了解标准的情况，一上来就 Hiberante 和 JPA 混为一团。

JavaEE/Jakarta EE 开发一般依赖应用服务器默认使用哪种（当然大部分服务器的标准组件是可以换成其他的），EclipseLinks 和 Hibernate 比较常见。

[Cbdy]

JPA 是 Java 过度设计时代的产物，是 OO 狂热时产生的设计

倒也不是完全不能用，在一些小的场景有点用，但大多数时候还是建议写 SQL

[onikage]

和姿势没关系, 还是要看项目, 一些简单项目, 没几张表的, 表关系简单的, 用 jpa 的话数据库相关工作量基本可以忽略. 这些工作我认为 JPA 比 mybatis 省事很多. 一些行业特定的项目, 几十个表, 几十个字段的, 还是得 mybatis,

[lonelymarried]

确实难用，还不如用 mybatis，写 raw sql 方便

[XiLemon]

@iamppz #28 您说的交给原生 SQL 处理指的是什么方式呢，用 @Query 注解吗，确实没有银弹，但是有相对的比较嘛

@wc951 #29 确实缺乏这方面的理解

@idoggy #30 能说的具体一点么 -_-||

@hantsy #32 确实不熟悉 JPA，记得刚开始学习 Java 这一套时，主流框架还是 SSH，然后转变成 SSM 了。Hibernate 这个词最早还是在 Win10 休眠启动的时候学会的这个词儿~~~，学习过 MyBatis 的部分源码，Hibernate 未曾了解过。

@Cbdy #34 -_-|| 大佬制定规则，打工人照着搬砖。。。

@onikage #35 主要 MyBatis 更自由吧

@lonelymarried #36 0.0... 确实习惯了 MyBatis 这一套

[mmdsun]

spring data jpa 也能用外部 xml 文件写 SQL 不是非得用注解，参考 XML named query 。
update 指定条件，jpa 一般都是先 select 出来再 set 值更新的。
如果你在用 ORM 框架写 SQL 的话，那本身出发点就错了。尝试用"对象导航"方式获取数据，jpa 是可以配置一对多关系的。
如果你的业务是超过 3 张表关联又需要各种组合条件查询那还是 mybatis 适合，另外反思架构的设计是否合理。

[passerbytiny]

虽然 JPA/Hibernate 从来并且也不计划抛弃 NativeSQL，但是你要不会完全脱离 NativeSQL 的纯 OOP 编程，还是死了用 JPA 的心吧。

简单来说，SQL 与 JPA 互斥。

[mikulch]

@hantsy 这两本书是不是都挺老了呀

[winglight2016]

@XiLemon #25 OOP 现在似乎已经不流行了，我也不知道还有什么比较新的资料，可能《 head first oop 》可以看看吧。

OOP 是个思维模式，也许可以从需求分析到实体设计这个流程试一下。

[XiLemon]

@mmdsun 关联没有超过 3 张表
@passerbytiny 我也不想用诶
@winglight2016 >…<

[hantsy]

@mikulch Java Persistence with Hibernate 最初是 06 年发布, JPA 1.0，人邮出版的影印版本正文有 800 多页。本来之前有一个 Hibernate in action 。这本书算是 Hibernate in action 第二版。

http://jpwh.org/

Java Persistence with Hibernate 第二版已经更新到了 JPA 2.1, 而后面 JPA 2.2 仅有几个 API 变化, 主要为了与 Java 8 API 对齐。

https://github.com/hantsy/ee8-sandbox

虽然 JPA 3.0 发布了（ Jakarta EE 9，2020 年），但其 API 与 JPA 2.2 完全一样 ，只是移到 Eclipse 下换了 Namespace(javax->jakarta)，引入了 API 不兼容。

Java EE/Jakarta EE 标准变化的没那么快，Spring 5 才更新到 Java EE 8/Jakarta EE 8.

[hantsy]

@onikage 如果脑子里面的都是表，基本用不来 JPA 。

以前我们一个项目，最终 200 个表，使用 JBoss Seam 框架写的（基于 JPA+JSF+EJB3 标准）。

[charlie21]

OOP 是最帮助产生就业岗位的，通过权限因素（比如 继承 封装 多态 接口）把很简单的事写得很复杂（一个函数或一句 sql 能搞定的呢现在多了 n 个类）放在历史项目里又要人维护，越能凭空增加工作量就越能给 IT 行业增加多少就业岗位。

OO 时代是不能过去的，如果相对的 FP 时代起来了那么等于在 “开发快但就业岗位少 or 开发慢但就业岗位多” 的选择里 搬起石头砸自己的脚 ... 依附于 OO 的 JPA 推得动是有原因的，尤其在国外。你可以说 这就是闭眼坑雇主，但凭空制造多几个就业岗位 同事会感谢你 未来的你也会感谢现在的自己。

最好一边感谢 OO 带来的就业空间一边学习 OO 向的技能。OOP 作为 solid engineering 思维模式本身是没啥好学的，但帮助了 IT 行业的横行扩展的社会工程学因素就是它了、IT 行业何德何能制造了这么多就业岗位呢 原因就是它了。

是设计过的。是醉翁之意不在酒的

[hantsy]

@onikage 再扯远一点，经常看看有人讨论 DDD 。

可以看看 DDD 原书代码中，在抽象 Domain Models 的时候根本就不考虑 ORM 。

https://github.com/citerus/dddsample-core/tree/master/src/main/java/se/citerus/dddsample/domain/model

考虑到 Data Persitence 的时候，才用到 ORM 。

https://github.com/citerus/dddsample-core/blob/master/src/main/resources/hibernate.cfg.xml

可以看出这个例子中 Classes 与表设计对应上有多大差别。

在 Hibernate 开始诞生的时候，就有很多关于 ORM 中 Object 和 Relation 应该不一致（ Mismatch ） 的文章，来表述 OOP 设计与面象数据设计的差别。

直到现在国内的程序员大多数都是面象数据的思维。这主要源于大学多少学过一点 SQL，用 MyBatis 拿来就可以上手而已。而 Hibernate 这种框架，本身背后有一套自己的设计体系，不仅仅是一个 ORM 那么简单。

[hantsy]

@Kirsk

Spring 框架本身对 JPA 进行了深度集成，使用 LocalContainerEntityFactoryBean, 可以完全去掉 JPA 的配置文件（ orm.xml, persitence.xml ， 目前在 Java EE 中，前者可选，后者是必须的），本身就是对 JPA 的 Local EntityManager 使用上简化，同时失去了在分布式 XA 环境下的功能。JPA 一个主要的目的是在 Java EE 规范上代替 EJB 2 的 EntityBean 规范，而 JPA 一个主要的场景就是与 EJB 3.x 结合使用。

Spring Data JPA 前身是 hades （不知道是这个名字，忘记了）是对 Hibernate 的封装。hades 正式被 Spring 吸引后，成立了 Spring Data 项目，Spring Data JPA 是 JPA 的封装，实际上国内大部分人都是用一个 Repository 类而已，对 JPA 本身了解的人很少。

https://github.com/hantsy/ee7-sandbox/tree/master/jpa （ JPA 2.1 新增功能，Java EE 7, 2013 年）

https://github.com/hantsy/ee8-sandbox/ 以 JPA 开头的项目（ JPA 2.2 新增功能很少，Java EE 8, 2018 年，Jakarta EE 8，2019 年）

[php01]

去看看弱类型语言的 orm，比如说 php 的。写起来让你感动到想哭

[hantsy]

@php01 Doctrine 基本复制了 Hibernate 概念, 写起来也差不多，只是 OOP 方面，PHP 语言本身还有欠缺，写起来肯定不如 Hibernate 舒服。

https://github.com/hantsy/angularjs-zf2-sample/blob/master/module/Album/src/Album/Model/Album.php （现在我 PHP 关注的少，现在 PHP 8 可以直接使用 Attribute 来写，代替 Comment 中的 Annotation ）

[php01]

@hantsy 看看 Eloquent 呗，谁还用玩具呀

[nicevar]

应用场景问题，JPA 用于后台管理这类比较方便，比如 zf 企业前端喜欢用 extjs，能直接绑定，配合 lombok 这类插件绝大多数情况数据查询逻辑都不用写，直接就完事了。
很多公司的项目都是这样，后台管理用 JPA，提供 API 服务之类的模块不用

[hantsy]

@php01 我们不讨论吧。我过了玩泥巴的年龄。

首先，PHP 从 5.2 提供大部分强语言特性，不再是弱类型语言。2，Doctrine 不管哪个方面都是比 Eloquent 更胜一筹。Doctrine 还有 Symfony 影响了很多 PHP 的语言特性和工业标准（ PSR 等）。

[php01]

@hantsy 你说的第二点，Doctrine 和 Eloquent，谁更好，或许每个人有每个人的标准。但是你说的第一点，这个是有标准的，PHP 就是弱类型语言，只是他的特性可以提供强类型供人们选择而已。

[SkyLine7]

楼主用的是 springdata jpa 吗 我觉得还行 就是 sql 调优比较难

[XiLemon]

@SkyLine7 #54 对呀，感觉很不习惯，现在配合 QueryDSL，感觉好点吧，-_-||

[unbright]

复杂的 querydsl 还行，就是可读性。。。。。而且对数据库的有些原生函数支持较弱，可以用 expression，一般来说如果关联表非常多的话要么就是设计没做好，要么就是需求没弄好（狗头），可以结合大数据任务写入 es，查询尽量简单

[XiLemon]

@unbright #56 最后还是用了 QueryDSL，感觉还行。帮别的组做东西，需求确实很凌乱，很坑。

[15190049162]

我感觉 JPA 太理想化了，很多复杂的 SQL 支持的并不好，但是自动生成简单 SQL 还是很香的，要是 mybatis 支持自动生成简单 SQL 也挺好的。反正我用 mbp

[ychost]

JPA 比较麻烦且生成的 SQL 比较难看，之前我也特别喜欢用 JPA 但是每次都得去复制 JpaSpecification 的 API 很麻烦，用多了还是觉得 tk.mybatis 比较香一点

[hwlfcwl]

不要用 jpa, jpa 用的是很爽,但是底层自动生成的 sql 语句在一些关联过多的地方会产生过度联表查询，导致数据库压力过大。而如果由开发者介入，去忽略一些关联，确实能缓解问题，但则随着模型越多，需要修改的地方也在增加，不利于代码的维护。还不如一开始手写 sql 一把梭哈呢。 总之很鸡肋。

[dandankele]

@cgpiao 那 java 应该用在啥地方好啊？