Spring Data JPA 與 MyBatis 對比,你喜歡用哪個?

來源:jianshu.com/p/3927c2b6acc0
概述
Spring Data JPA是Spring Data的子模塊。使用Spring Data,使得基于“repositories”概念的JPA實現更簡單和容易。Spring Data JPA的目標是大大簡化數據訪問層代碼的編碼。作為使用者,我們只需要編寫自己的repository接口,接口中包含一些個性化的查詢方法,Spring Data JPA將自動實現查詢方法。JPA默認使用hibernate作為ORM實現,所以,一般使用Spring Data JPA即會使用hibernate。我們再看看hibernate的官方概念,Hibernate是一個開放源代碼的對象關系映射框架,它對JDBC進行了非常輕量級的對象封裝,它將POJO與數據庫表建立映射關系,是一個全自動的orm框架,hibernate可以自動生成SQL語句,自動執(zhí)行,使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫。
MyBatis 是一款優(yōu)秀的持久層框架,它支持定制化 SQL、存儲過程以及高級映射。MyBatis 避免了幾乎所有的 JDBC 代碼和手動設置參數以及獲取結果集。MyBatis 可以使用簡單的 XML 或注解來配置和映射原生信息,將接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java對象)映射成數據庫中的記錄。
這樣看,Spring Data JPA與MyBatis對比,起始也就是hibernate與MyBatis對比。所以,我們直接來比較后兩者。
Hibernate 與 MyBatis 簡單對比
從基本概念和框架目標上看,兩個框架差別還是很大的。hibernate是一個自動化更強、更高級的框架,畢竟在java代碼層面上,省去了絕大部分sql編寫,取而代之的是用面向對象的方式操作關系型數據庫的數據。而MyBatis則是一個能夠靈活編寫sql語句,并將sql的入參和查詢結果映射成POJOs的一個持久層框架。所以,從表面上看,hibernate能方便、自動化更強,而MyBatis 在Sql語句編寫方面則更靈活自由。
但這只是從使用層面上看兩者的區(qū)別,并未涉及的本質。但如果看問題,值看淺層次、表象問題的話,就不能理解技術本質,也不能發(fā)揮技術的最多效用。所以,如果更上一個抽象層次去看,對于數據的操作,hibernate是面向對象的,而MyBatis是面向關系的 。當然,用hibernate也可以寫出面向關系代碼和系統,但卻得不到面向關系的各種好處,最大的便是編寫sql的靈活性,同時也失去面向對象意義和好處——一句話,不倫不類。那么,面向對象和關系型模型有什么不同,體現在哪里呢?實際上兩者要面對的領域和要解決的問題是根本不同的:面向對象致力于解決計算機邏輯問題,而關系模型致力于解決數據的高效存取問題。我們不妨對比一下面向對象的概念原則和關系型數據庫的不同之處:
面向對象考慮的是對象的整個生命周期包括在對象的創(chuàng)建、持久化、狀態(tài)的改變和行為等,對象的持久化只是對象的一種狀態(tài),而面向關系型數據庫的概念則更關注數據的高效存儲和讀??; 面向對象更強調對象狀態(tài)的封裝性,對象封裝自己的狀態(tài)(或數據)不允許外部對象隨意修改,只暴露一些合法的行為方法供外部對象調用;而關系型數據庫則是開放的,可以供用戶隨意讀取和修改關系,并可以和其他表任意的關聯(只要sql正確允許的情況下); 面向對象試圖為動態(tài)的世界建模,他要描述的是世界的過程和規(guī)律,進而適應發(fā)展和變化,面向對象總是在變化中處理各種各樣的變化。而關系型模型為靜態(tài)世界建模,它通過數據快照記錄了世界在某一時候的狀態(tài),它是靜態(tài)的。
從上面兩者基本概念和思想的對比來看,可以得出結論hibernate和MyBatis兩個框架的側重點完全不同。所以我們就兩個框架選擇上,就需要根據不同的項目需求選擇不同的框架。在框架的使用中,也要考慮考慮框架的優(yōu)勢和劣勢,揚長避短,發(fā)揮出框架的最大效用,才能真正的提高項目研發(fā)效率、完成項目的目標。但相反,如果使用Spring Data JPA和hibernate等ORM的框架而沒有以面向對象思想和方法去分析和設計系統,而是抱怨框架不能靈活操作sql查詢數據,那就是想讓狗去幫你拿耗子了。
Hibernate 使用步驟
那么,話題再說回來,使用兩個框架時候的時候,也要注意最佳的步驟和流程。下面我們來分別討論一下,hibernate的一般使用步驟如下:
分析、抽象和歸納出系統中的業(yè)務概念,并梳理出各個業(yè)務概念之間的關系——創(chuàng)建概念模型 根據概念模型,進一步細化設計系統中的對象類以及類的依賴關系——創(chuàng)建設計模型 將設計好的類映射到數據庫的表和字段配置好 hibernate可以根據配置信息自動生成數據庫表,這個時候也可以集中精力去梳理一下表關系,看看表結構是否合理,并適當調整一下類和表的映射關系,重新生成表結構
完成以上步驟,基本上完成了體統中主要的業(yè)務概念類和表結構的設計工作,只是完成表結構設計的出發(fā)點事如何持久化系統的對象,同時兼顧數據庫表、字段、字段類型、表的關聯關系的合理性和合規(guī)性,而不是單純表設計。這兩者思考和關注點還是有很大差別的。另外,需要說明一點,這只是使用hibernate的最通用步驟,實際操作過程中還是需要根據具體項目情況來安排。
MyBatis 是使用步驟
而MyBatis對于面向對象的概念強調比較少,更適用于靈活的對數據進行增、刪、改、查,所以在系統分析和設計過程中,要最大的發(fā)揮MyBatis的效用的話,一般使用步驟則與hibernate有所區(qū)別:
綜合整個系統分析出系統需要存儲的數據項目,并畫出E-R關系圖,設計表結構 根據上一步設計的表結構,創(chuàng)建數據庫、表 編寫MyBatis的SQL 映射文件、Pojos以及數據庫操作對應的接口方法
這樣看來MyBatis更適合于面向關系(或面向數據、或面向過程)的系統設計方法,這樣的系統一般稱為“事務腳步”系統(事務腳步(Transaction Script) 出自Martin Fowler 2004年所著的企業(yè)應用架構模式(Patterns of Enterprise Application Architecture))。而hibernate(也可以說Spring Data JPA)更適合于構建領域模型類的系統。當然,我們也不能說MyBatis無法構建領域模型驅動的系統,而hibernate無法構建事務腳步系統。只是用MyBatis構建領域模型要做更多、更臟、更累的工作;而用hibernate構建一個事務腳本系統有些大材小用,數據的查詢反而沒那么靈活。
小結
綜合上面所有描述和對比,我們對這兩個框架的本質區(qū)別應該有所了解了。我們了解了這些區(qū)別,可以幫助我們選擇更合適的框架,同時,也可以利用不同的框架,讓他們去做更合適事,這也是所謂的物盡其用吧,更不至于我們“為物所役”。
最近面試BAT,整理一份面試資料《Java面試BATJ通關手冊》,覆蓋了Java核心技術、JVM、Java并發(fā)、SSM、微服務、數據庫、數據結構等等。
獲取方式:點“在看”,關注公眾號并回復 Java 領取,更多內容陸續(xù)奉上。
文章有幫助的話,在看,轉發(fā)吧。
謝謝支持喲 (*^__^*)

