持久層框架JPA與Mybatis該如何選型
一、現狀描述
目前java 持久層ORM框架應用最廣泛的就是JPA和Mybatis。JPA只是一個ORM框架的規範, 對該規範的實現比較完整就是Spring Data JPA（底層基於Hibernate實現），是基於Spring的資料持久層框架，也就是說它只能用在Spring環境內。Mybatis也是一個優秀的資料持久層框架，能比較好的支援ORM實體關係對映、動態SQL等。
筆者在學習這兩個框架的過程中，看過不少的帖子，每當有帖子比較這兩個框架的優缺點，就引來一場論戰。從筆者的角度，為什麼國內的開發人員或者開發團隊較少使用JPA？為了避免有人抨擊我，我特意去做了一下國內某度指數搜尋，這個資料騙不了人。
圖中藍色線條為Mybatis搜尋量，綠色為JPA搜尋量。如果你換一個國外的搜尋指數，你會得到一個完全不同的結果。那麼這是為什麼呢？我們還要從JPA的特點說起：
- JPA對於單表的或者簡單的SQL查詢非常友好，甚至可以說非常智慧。他為你準備好了大量的拿來即用的持久層操作方法。甚至只要寫findByName這樣一個介面方法，他就能智慧的幫你執行根據名稱查詢實體類對應的表資料，完全不用寫SQL。
- 但是，JPA對於多表關聯查詢以及動態SQL、自定義SQL等非常不友好。對於JPA來說，一種實現實現方式是QueryDSL，實現的程式碼是下面這樣的。我想問：你希望用這樣的程式碼代替SQL麼？
JPAQueryFactory queryFactory = new JPAQueryFactory(em); JPAQuery<Tuple> jpaQuery = queryFactory.select(QTCity.tCity,QTHotel.tHotel) .from(QTCity.tCity) .leftJoin(QTHotel.tHotel) .on(QTHotel.tHotel.city.longValue().eq(QTCity.tCity.id.longValue())); //新增查詢條件 jpaQuery.where(predicate); //拿到結果 return jpaQuery.fetch();
另一種方法是使用NativeQuery，我仍然想問：你希望在java程式碼裡面用拼字串的方式寫SQL麼？
@Entity @NamedNativeQueries(value={ @NamedNativeQuery( name = "studentInfoById", query = " SELECT * FROM student_info " + " WHERE stu_id = ? ", resultClass = Student.class ) }) @Table(name="student_info")
以上的這部分實現還沒有考慮到動態SQL的問題，如果考慮到動態SQL，寫法會更復雜。所謂的動態SQL就是：根據傳入引數條件的不同，構造不同的SQL，很多的比較這兩個框架的文章都忽略了動態SQL的問題，這方面Mybatis支援的更好。Mybatis寫的動態SQL說到底還是SQL，而不是java程式碼或者java程式碼拼字串。程式設計師特別排斥幾件事：
- 將複雜關聯關係的SQL寫在java程式碼裡面，拼串書寫不方便
- SQL是最能表達實體關係查詢的語言，程式設計師不希望使用異化SQL語言。
- 程式設計師不希望學習不通用的東西，顯然SQL大家都會
- JPA雖然將大部分操作封裝起來了，也挺好用的，但是SQL調優怎麼做？
可以使用Spring-Data-JPA-extra解決JPA的拼串書寫和SQL異化的問題。但是根據筆者的使用情況，Spring-Data-JPA-extra是一個個人開發者專案，用於生產還很不成熟，對於多資料來源處理、複雜型別處理等還有很多的問題。
二、劣幣驅逐良幣？
然而，另外有一派觀點，你看人家國外的程式設計師怎麼都用JPA？你不去學習新東西，還不讓別人用？JPA使用很方便啊，唯一缺點就是複雜關聯SQL支援差一點,但是隻要你學一下也還可以支援啊，你們這是劣幣驅逐良幣。如果經過很好的實體關係模型的設計，JPA顯然是最優解，程式設計師寫的SQL還真不如JPA根據實體關係生成的SQL。筆者要說，這種觀點也是有道理的。但是，筆者要說並不是國內程式設計師不願意學習，而是另有原因。
- 首先，筆者長年從事遠端工作，與國外程式設計師接觸較多。他們習慣使用JPA的一個原因，真的是因為他們國家的應用規模太小了，比起國內的一個應用動則上百萬的使用者相比，他們在資料庫設計與調優的需求上顯然更從容。
- 國外的應用設計往往更簡潔，而國內的應用需求往往功能性更強。如果不信，你可以去看看工作流，什麼會籤、流程回退什麼的都是我們發明的，他們沒有。你讓他們用JPA寫一個我們的工作流應用試一試，累吐血他們也做不到。
- 異化SQL或者程式碼裡面寫SQL，一定程度上增加了學習成本和使用成本。所以用的人少，用的人少你就得遷就團隊中的大部分人。
說完以上幾點，Mybatis為什麼在國內會有如此多的使用者及使用廠商就不難理解了。Mybatis還可以使用如：Mybatis-plus或者程式碼自動生成來彌補易用性上的不足。JPA的身材、家室、性格樣樣都是滿分，就是臉長得磕磣點難以處理社交關係。Mybatis雖說在各方面都不優秀，身材還可以、樣貌也還說得過去、性格也還好。關鍵是你說什麼都聽你的，還有願意幫他化妝的朋友。要你說你選哪一個？
那麼，有的人會說，你這是擡槓？國外就沒有受眾數量多、功能性強的網際網路應用了麼？恐怕比國內還多吧，這個也是事實。但是從比例上講還是國內更多，比例決定開發人員選擇技術的方向。這也導致了一個慣性思維，他們平時就用JPA學習訓練，所以寫大型服務應用的時候也用JPA。那麼，他們寫JPA會寫複雜SQL麼？答案是很少會用到，甚至有的國外公司就明令禁止寫關聯查詢SQL。那怎麼辦？不用關聯SQL怎麼開發業務需求？不會啊。
三、服務拆分或微服務
國內現在也有越來越多的公司，進行微服務的落地，然而真正落地比較好的企業少之又少。這和多表關聯查詢有什麼關係？我們先來實現這樣一個需求：查詢屬於A角色相關的所有的業務B資料。
- 如果我們開發的是傳統的單體應用，我們可能是把角色表A和業務表B進行關聯查詢，然後得到查詢結果
- 如果我們做的是微服務，我們可能是拆分為許可權服務A、業務服務B。先去訪問A服務介面獲取角色標誌資訊，然後再根據角色標誌資訊去業務服務B介面獲取業務資料。
那麼有的人會說，訪問兩個介面一定比訪問一個介面更慢吧！這個真的不是，如果我們做微服務，一定是我們的應用規模及資料量到達了一定程度。也一定會考慮分表分庫、負載均衡、服務拆分細化等問題，當分散式的開發方式被應用越多，多表關聯查詢使用的機會也就越少。拆分後的服務由於功能單一、負載分流等原因，訪問速度往往比大資料量資料集中儲存、多服務集中部署的應用會快很多。
問題回來了，不用關聯SQL怎麼開發程式？總的來說就是通過合理的服務拆分、應用的介面資料的組織關係的合理的設計，團隊擁有比較好的微服務落地經驗，是可以實現不使用關聯查詢SQL開發應用的。大家也知道，NOSQL越來越流行，絕大部分的NOSQL資料庫都沒有所謂的關聯關係。
四、框架對比選型
| 對比項 | Spring Data JPA | Mybatis |
|---|---|---|
| 單表操作方式 | 只需繼承，程式碼量極少，非常方便。而且支援方法名用關鍵字生成SQL | 可以使用程式碼生成工具或Mybatis-Plus等工具，也很方便，但相對JPA要弱一些。 |
| 多表關聯查詢 | 不太友好，動態SQL使用不夠方便，而且SQL和程式碼耦合到一起 | 友好，可以有非常直觀的動態SQL |
| 自定義SQL | SQL寫在註解裡面，寫動態SQL有些費勁 | SQL可以寫在XML裡面，是書寫動態SQL語法利器。也支援註解SQL。 |
| 學習成本 | 略高 | 較低 ,基本會寫SQL就會用 |
總結一下筆者的觀點：
- 如果你是自己開發“小而美”的應用，建議你使用JPA
- 如果你是開發大而全的企業級應用，當然要遵從團隊的技術選型。這個技術選型在國內通常是Mybatis。
如果你們公司的管理非常規範，微服務落地經驗也非常成熟，可以考慮在團隊專案中使用JPA。少用或不用關聯查詢。
期待您的關注
- 博主最近新寫了一本書：《手摸手教您學習SpringBoot系列-16章97節》
本文轉載註明出處（必須帶連線，不能只轉文字）：字母哥部落格。