我真的不想再用 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 的項目了。

不要吝惜你的「推薦」呦

歡迎關注，不按期更新本系列和其餘文章
古時的風箏 ，進入公衆號能夠加入交流羣