愿个人世界不会再有 JPA

在开发者的圈子里，没当说到一种技术好或者很差，都会引起激烈或者不激烈的争论，直到一个开发者出来讲 PHP 是世界上最好的语言，你们伙儿才会纷纷退去继续写代码。

今天说 JPA 的问题不是想引起什么讨论或者骂战，单纯的就是我不喜欢 JPA 。没错，就是这么 Real。

说到 Java 开发，涉及到数据库访问的，主要就两种框架，一个是 MyBatis ，另外一个就是 JPA。听说是国外 JPA 用的比较多，国内 MyBatis 用的比较多。国内为何 MyBatis 用的多呢，传说是由于整个阿里系都用它。

JPA 全称是Java 持久化 API ，它的目的就是帮助咱们提升开发效率，它的核心是 Java持久化查询语言 （JPQL），对存储在关系数据库中的实体进行查询。在语法上相似于SQL查询，可是操做的是实体对象而不是直接对数据库表进行操做。(摘自 wiki)

使用 JPA 开发的流程以下：一、将数据库表映射到项目实体中 二、生成对应的 Repository 三、实现 Service ，Service 中调用 Repository JPA 帮你省事儿的地方就在 Repository 里，对于那些比较简单的逻辑，好比单表查询，直接根据名字就能够实现查询逻辑。对于大部分查询来讲，真的很省事儿。但刚开始用的时候，确实感受有些莫名其妙。

确实如此，若是你用过 JPA ，有些时候它确实对开发效率有很大提高，JPA 想要作的就是尽可能让你少写 sql，甚至不写 sql。基于这种思想，JPA 实现了它本身的一套语法、注解规则。

JPA 要用各类注解配合来实现数据实体间的一对多、多对多等等的关联关系。正由于这样，我以为实体变得不单纯是实体，而是掺杂的逻辑在里面，也增长了实体的复杂度，对于比较复杂的业务来讲，很容易形成实体间直接或间接的循环引用。

你若是想用 JPA，除了要掌握各类注解外，对于稍微复杂的查询，还要掌握它的那套写法，好比下面这种代码：

Specification<CmContent> specification = (root, criteriaQuery, criteriaBuilder) -> {
Predicate p = criteriaBuilder.equal(root.get("deleted").as(Boolean.class), false);
Predicate news = criteriaBuilder.equal(root.get("cntntType"), ContentType.CNTNTTP_NEWS.name());
Predicate salon = criteriaBuilder.equal(root.get("cntntType"), ContentType.CNTNTTP_SALON.name());
Predicate type = criteriaBuilder.or(news, salon);
...

并且你想要实现一个 join 查询也是够费劲的，除了要写上面那套代码外，还要在实体上作手脚，想到就想哭，有没有。难道直接写个 sql 很差吗，为何要这么糟蹋本身。

还有一点，JPA 有些注解用上了以后会影响到数据库层面，比方说关键外键的注解，若是你用默认设置，这个外键就真的会应用到数据库表里，在表上建外键。还有其余的一些 ORM 框架也是如此，这是我彻底不能接受的，凭什么，凭什么在个人数据库上改东西。

愿我参与的项目中没有 JPA。公司有个项目用到了 JPA ，我也参与了一部分，写的代码不算多，除了令我头疼以外，没有体会到 JPA 的半点好处，这其中固然极可能是因为个人水平有限，或者说我写的 JPA 代码不够多，或者我根本没有领会到 JPA 的精髓所在。总之无论怎么样，对不起，愿我不会再碰到 JPA。

固然这么说确定是有失偏颇，有些同窗可能会对此嗤之以鼻。没错，有同事就是这样说的：事物存在即合理，JPA 这么多年了，若是很差用怎么会还有这么多人用，并且国外 JPA 使用者众多，难道人家都有问题。

若是只是简单的项目，业务一点也不复杂，不复杂到连个 join 都没有的项目，能够用 JPA ，其余的状况下，真的不用它最好。用 JPA 的感受就像是被绑上了手脚，失去了自由。不自由，毋宁死。纵使千般好，少了自由，我就拒绝它。而 MyBatis 偏偏就是给开发者自由的一个框架。

最近对以前一个项目加一些功能，这个项目用的是 JPA。下面这段代码，也充分证实了我有多么讨厌 JPA。

仍是那句话，不自由，毋宁死。这是第一个，恐怕也是最后一个用 JPA 的项目了。