jpa多表關聯查詢_淺談mybatis和jpa的差別

其實要承認，一個東西用久了都會有習慣心理。mybatis和jpa，兩個持久層架構。從底層到用法都不同。但是實作的功能是一樣的。是以說一直以來頗有争議。常年混迹于各大qq技術交流群。見過jpa的死忠粉也見過mybatis的鐵杆。作為一個不到兩年工作經驗的小菜鳥來說，你讓我分析源碼，講什麼底層實作我是講不出來的。隻能作為一個使用者，來談談自己對這兩個架構的了解。

首先，都知道jpa的前身是著名的ssh中的h——>Hibernate。我到現在還記得學習Hibernate時對它産生的講解：一個希望不用寫sql語句來操作資料庫的懶到願意為此開發一個架構的創始人，其實也夠奇葩到值得記住了。而現在的jpa，我覺得主旨也确實在貫徹這個理念。你要承認，jpa的對于單表的簡單查詢确實簡單友善又實用。但是同時，對于多表關聯和複雜查詢，起碼目前為止，要麼把複雜查詢拆成多個簡單查詢，要麼甯可直接一個nativeQuery = true來原生查詢。如果這兩點都沒能滿足你業務的需求，我不敢下定結論說你的設計有問題，但是如此複雜的業務邏輯，身為小白的我實在無法給你建議了。

然後說到mybatis，原諒我入行時間比較晚。從我開始學習java他就已經出現了。聽說過他前身好像是ibatis,但是具體就不太了解了。使用上來講，在那個boot還沒有釋出的年代，mybatis也曾經是每個程式員必備的基本技能。剛接觸的時候mapper映射在我眼中簡直是神奇。也算是用了半年多，多少有一定的了解。在這裡基本的使用就不多介紹了，反正我一直所應用的也基本都是crud。沒到多高深的地步。隻能說對于多表查詢确實是比較支援。尤其是在業務邏輯多是多表關聯的情況下，mybatis絕對比jpa要更加适合。無論是以後的維護還是業務的變更都友善不少。

可能我這麼說大家還是不太了解什麼時候用jpa什麼時候用mybatis。我舉個例子：現在業務上A,B,C,D四個表。如果你每個表都會在業務中用到，都需要有單獨的增删改查，雖然有一定的關聯關系，但是這種情況用jpa就比較合适。ABCD四個java實體不說，每個實體要對應一個repository。然後再repository層進行crud的編寫。但是如果業務上A,B,C,D四個表。這四個是關聯關系，你幾乎不會單獨對A,B,C進行操作，而且展現出來的也是D，那麼這個時候jpa的使用就會很麻煩，因為你還是要四個實體四個repository。在一個接口中四個repository挨個調用一次。雖然也能完成業務邏輯，但是複雜又麻煩。還要考慮原子性什麼的。是以這個時候用mybatis比較合适了。

其實說到這大概對于什麼樣的業務應該采用哪個在思維上應該有個簡單的區分了。不過很多時候很多項目不是能一下子分辨出來屬于哪種的。是以還是需要具體判斷的。雖然工作才一年多，但是外包讓我經曆了多個項目的經驗告訴我，千萬别相信那些所謂的“某某大佬”随便給你的建議。（我是指那些連具體業務都不知道就給你建議jpa好還是mybatis好的那種。如果真的是大佬而且願意為你的項目深入分析并且給出答案，那還是值得參照的）因為以前有一次在老闆給了我一個小項目讓我獨立完成的時候我選擇了咨詢群裡的大佬。記得很清楚當時大佬給的意見就是mybatis。還說了mybatis的好多優點。然後我就自然而然的用了。結果嘛，大家能想到我一個人能完成的項目會有多小，業務多簡潔。雖然用mybatis也做完了。但是現在想想，要是換成jpa肯定會更加快速友善的開發。我講這段經曆絕對沒有别的意思，隻是想告訴大家業務怎麼樣還是自己最清楚。很多時候我們的詢問可能不是很全面，是以别人給的建議也不是很合适。

然後還有一些額外的東西。比如說spring家族的态度。我不知道各位有沒有跟我一樣的大衆心理。一個jar包。隻要是org.springframework.boot這個分組的，就比較信賴。畢竟有那麼龐大的家族做後盾呢~~而且boot真的是封裝的越來越具體了~~~反正依稀記得以前spring建立個項目，還要配置這個那個的，偶爾馬虎下還報個錯。一個結構要搭好一會兒的（也可能是我當時比較菜，但是确實要配置一些東西）而現在呢，spring boot，差不多建立了，依賴導一下就可以跑。真的是相當友善。友善到前一段時間群裡一個小孩子問了一個spring 配置的問題，我居然覺得有點想不起了~~哎~~spring boot用多了，都把人用成sb了~~~哈哈，開玩笑的，别當真。反正現在代碼的高度封裝讓我們用什麼都更加簡單了。而boot對jpa的封裝，反正我個人是覺得在單純的配置上面，除了在配置檔案中連接配接下資料庫然後添加個data-jpa的依賴，搞定了就。這也是個人比較喜歡jpa的一點。部署是真的簡單。而且官方文檔還很全面。也在持續維護更新。我覺得單純從spring的角度，jpa就值得一試。當然了，這個屬于個人心态，但是如果是新手在自己做練手項目的時候，我還是推薦jpa。

對了，再額外安利一下，這個就涉及到了個人的使用經驗。以前隻有mybatis有代碼生成器，是以基于這個原因有一段時間我還比較喜歡用mybatis。但是現在jpa也有了代碼生成器。從表到實體和從實體到 表都可以自動生成的。小白們别手敲啦~~~（ps：是因為我以前做過這種事是以在此提醒一下跟我一樣白的小盆友，知道的可以掠過）。至于代碼生成器的使用，隻要你知道了這個概念去百度都能找到用法，在這裡我就不多說了。實在不知道的也可以問我，我要是看到了會回的，雖然我覺得找我不如自己百度呢。

然後再說個題外話，其實jpa和mybatis都是很有必要學的。因為遇到的項目會各種各樣，是以兩者各有長短。還有就是如果自己沒話語權的時候，最好上級讓用啥就用啥。注意！我說的是最好。如果說你們team氛圍比較好，然後上司比較願意接受意見什麼的，你出與實際考慮确實有不同的意見可以提出來。不然的話還是老老實實聽指揮吧。别管你以為有多不合理。我不是在宣揚什麼消極理念。而且在一個team中上司所考慮的可能和你考慮的點不一樣。或者說你知道的不太全面等。沒必要非要為了所謂的自己為正确然後最後弄的大家都不愉快。尤其是最後還可能結果也不會想你想的那樣。大家都是做技術的，有點自視清高或者說自己的見解很正常。但是切記人還是要謙卑。給大家講一個實際發生的故事。

我們team一直是手寫接口文檔，然後人工維護的。确實作在有很多文檔生成工具，我自己也用過swagger做過demo，但是團隊裡有的人不會用，而且其實維護起來也很麻煩（可能是沒用習慣的麻煩，這不是主要的），而且我們公司接的項目都比較小。是以上司說就手工維護接口文檔吧。然後前一段時間來了個實習的小孩，可能是學習确實很努力，接觸的技術很多。然後一開始整天也幹勁兒滿滿的自覺加班在公司學習到很晚那種。後來開了個項目，小孩看到我們手工維護接口可能是覺得比較low，是以跟我們上司建議用swagger。然後我們上司就很委婉的說他回去了解了解，考慮考慮再說，先這麼手工維護吧。然後自那以後我們再手動改接口，他就會講這樣怎麼怎麼，巴拉巴拉的。重點是有一次我們team中工作時間比較久的一個大哥因為接口對接沒對接好，是以測試的時候有點小bug，這個孩子又開始抱怨說用手寫文檔怎麼怎麼不好。。然後我們上司就爆發了，劈裡啪啦一頓訓斥，大概意思就是這裡的人誰不比他有經驗啊，他優越什麼啊，之是以不改是因為要前端後端都要熟悉這個架構，沒必要。。然後那以後這個小孩沉默多了，也不知道是頓悟了什麼還是說生氣。後來不久這個小男孩就走了。辭職還是被勸退也都不知道。其實單單從這個故事看，一個swagger的事，說不上誰對誰錯的。非要說的話，我們一個外包公司，肯定是需求對付做完就行了，老闆不願意拿時間來讓員工學習一些沒必要的技能。從小男孩的角度，一個實習生沒有決定權卻非要堅持主見。這個也算是職場經驗了 吧~~~說着說着跑題了~~~

反正核心幾句話“：

1，jpa和mybaits各有優缺點。

2，使用哪個合适要結合具體的業務進行分析。

3，當你沒有決定權的時候，最好上司讓用什麼用什麼。

對于咱們技術人員來講，兩個都要熟悉，會用。

作者：唯有努力不欺人丶

連結：https://www.jianshu.com/p/32ce87c163d6

來源：簡書

簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權并注明出處。