持久層框架JPA與Mybatis該如何選型

1、現狀描述

目前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是一個我的開發者項目，用於生產還很不成熟，對於多數據源處理、複雜類型處理等還有不少的問題。

2、劣幣驅逐良幣？

然而，另外有一派觀點，你看人家國外的程序員怎麼都用JPA？你不去學習新東西，還不讓別人用？JPA使用很方便啊，惟一缺點就是複雜關聯SQL支持差一點,可是隻要你學一下也還能夠支持啊，大家這是劣幣驅逐良幣。若是通過很好的實體關係模型的設計，JPA顯然是最優解，程序員寫的SQL還真不如JPA根據實體關係生成的SQL。筆者要說，這種觀點也是有道理的。可是，筆者要說並非國內程序員不肯意學習，而是另有緣由。

• 首先，筆者終年從事遠程工做，與國外程序員接觸較多。他們習慣使用JPA的一個緣由，真的是由於他們國家的應用規模過小了，比起國內的一個應用動則上百萬的用戶相比，他們在數據庫設計與調優的需求上顯然更從容。
• 國外的應用設計每每更簡潔，而國內的應用需求每每功能性更強。若是不信，你能夠去看看工做流，什麼會籤、流程回退什麼的都是咱們發明的，他們沒有。你讓他們用JPA寫一個咱們的工做流應用試一試，累吐血他們也作不到。
• 異化SQL或者代碼裏面寫SQL，必定程度上增長了學習成本和使用成本。因此用的人少，用的人少你就得遷就團隊中的大部分人。

說完以上幾點，Mybatis爲何在國內會有如此多的使用者及使用廠商就不難理解了。Mybatis還可使用如：Mybatis-plus或者代碼自動生成來彌補易用性上的不足。JPA的身材、家室、性格樣樣都是滿分，就是臉長得磕磣點難以處理社交關係。Mybatis雖然說在各方面都不優秀，身材還能夠、樣貌也還說得過去、性格也還好。關鍵是你說什麼都聽你的，還有願意幫他化妝的朋友。要你說你選哪個？

那麼，有的人會說，你這是擡槓？國外就沒有受衆數量多、功能性強的互聯網應用了麼？恐怕比國內還多吧，這個也是事實。可是從比例上講仍是國內更多，比例決定開發人員選擇技術的方向。這也致使了一個慣性思惟，他們平時就用JPA學習訓練，因此寫大型服務應用的時候也用JPA。那麼，他們寫JPA會寫複雜SQL麼？答案是不多會用到，甚至有的國外公司就明令禁止寫關聯查詢SQL。那怎麼辦？不用關聯SQL怎麼開發業務需求？不會啊。

3、服務拆分或微服務

國內如今也有愈來愈多的公司，進行微服務的落地，然而真正落地比較好的企業少之又少。這和多表關聯查詢有什麼關係？咱們先來實現這樣一個需求：查詢屬於A角色相關的全部的業務B數據。

• 若是咱們開發的是傳統的單體應用，咱們多是把角色表A和業務表B進行關聯查詢，而後獲得查詢結果
• 若是咱們作的是微服務，咱們多是拆分爲權限服務A、業務服務B。先去訪問A服務接口獲取角色標誌信息，而後再根據角色標誌信息去業務服務B接口獲取業務數據。

那麼有的人會說，訪問兩個接口必定比訪問一個接口更慢吧！這個真的不是，若是咱們作微服務，必定是咱們的應用規模及數據量到達了必定程度。也必定會考慮分表分庫、負載均衡、服務拆分細化等問題，當分佈式的開發方式被應用越多，多表關聯查詢使用的機會也就越少。拆分後的服務因爲功能單1、負載分流等緣由，訪問速度每每比大數據量數據集中存儲、多服務集中部署的應用會快不少。

問題回來了，不用關聯SQL怎麼開發程序？總的來講就是經過合理的服務拆分、應用的界面數據的組織關係的合理的設計，團隊擁有比較好的微服務落地經驗，是能夠實現不使用關聯查詢SQL開發應用的。你們也知道，NOSQL愈來愈流行，絕大部分的NOSQL數據庫都沒有所謂的關聯關係。

4、框架對比選型

對比項	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節》
• 本文轉載註明出處（必須帶鏈接，不能只轉文字）：字母哥博客。</tuple>