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

來源：https://www.cnblogs.com/zimug/p/11790285.html

目前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();
/<tuple>

另一種方法是使用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數據庫都沒有所謂的關聯關係。

四、框架對比選型

總結一下筆者的觀點：

• 如果你是自己開發“小而美”的應用，建議你使用JPA
• 如果你是開發大而全的企業級應用，當然要遵從團隊的技術選型。這個技術選型在國內通常是Mybatis。
• 如果你們公司的管理非常規範，微服務落地經驗也非常成熟，可以考慮在團隊項目中使用JPA。少用或不用關聯查詢。

最後，我自己是一名從事了多年開發的JAVA老程序員，辭職目前在做自己的java私人定製課程，今年年初我花了一個月整理了一份最適合2019年學習的java學習乾貨，可以送給每一位喜歡java的小夥伴，想要獲取的可以關注我的頭條號並在後臺私信我：【交流】，即可免費獲取。