關於SQL和ORM的爭論，永遠都不會終止，我也一直在思考這個問題。昨天又跟群裡的小夥伴進行了一番討論，感觸還是有一些，於是就有了今天這篇文。

宣告：本文不會下關於Mybatis和JPA兩個持久層框架哪個更好這樣的結論。只是擺事實，講道理，所以，請各位看官勿噴。

一、事件起因

關於Mybatis和JPA孰優孰劣的問題，爭論已經很多年了。一直也沒有結論，畢竟每個人的喜好和習慣是大不相同的。我也看過知乎上一些問答，各有各的理由，感覺都挺有道理。如果讓我不帶感情色彩地去分辨，其實我也是懵的，因為真的是公說公有理婆說婆有理。

而在國內，不得不承認，到今年（2019年），用Mybatis的公司確實是要比用JPA的多，但是在2015年以前，用Hibernate的公司確實也是很多的。為什麼在國內，會有這樣的現象發生？而在國外，老外會一如既往地使用JPA呢？我們來分析分析。

二、目前生態

在最近（2018）的JVM生態報告中（https://snyk.io/blog/jvm-ecosystem-report-2018-platform-application/），Mybatis是使用率是很低的。可以看圖：

可以看出，Mybatis的佔比只有可憐的6%，大家看到這個統計結果應該會很吃驚，你會覺得，不對啊，我公司以及我很多朋友都在用Mybatis啊，好像沒聽說過有人用JPA的，這個統計結果是錯的吧？造成這種印象的原因也很簡單，因為語言和技術的流行度有地域性偏差的，接著來看下Google Trends就明白了：

紅色部分是Mybatis的主要使用人群。

圖違規，刪除了。

再從下面這個對比來看，MyBatis的關注主要集中在中日韓。知道日韓為啥也高嗎，猜中有獎哦，哈哈！

首先，必須指出，對於青年程式設計師，其實都會質疑這個圖的可信度。中老年程式設計師都在感嘆國外其實更注重開發效率和麵向物件的分析和設計。但我可以非常負責任地告訴你，這圖是真的。那麼，造成這種現象的原因是？

三、國人喜歡Mybatis的原因

總結起來，有如下原因：

1.大廠帶節奏

國內做網際網路的Java程式很多都是拷貝阿里的，阿里一開始用例iBatis（日本韓國是怎麼回事呢）。大量的老系統都是基於iBatis/MyBatis的，市場上對MyBatis熟悉的人才更多，招聘和培訓更容易，有的青年程式設計師以為“MyBatis早已統一全球了”就是一個很好的證明。

2.簡單，學習成本低

小公司需要大量入門級的程式設計師，像大神甚至一個都請不起，請問大神們那些牛b框架哪個更快讓菜鳥們上手，降低公司學習成本。注意這個成本會一直跟隨公司，想必大神們創業直接前後端分離了，畢竟錢嘛多的是。

3.對於複雜性需求的靈活性高

國內絕大部分專案都是面向表結構程式設計的，把java物件僅當成資料容器，查詢和模型變更都設計在一張表上，所謂業務邏輯就是一堆增刪改查的sql集合，當然用mybatis方便。在邏輯不復雜，或者你判斷軟體生命週期不會超過一年的時候，直接用表結構程式設計是最方便快捷的。

國內普遍都是分散式，流量和效能決定了需要經常進行優化，而是用Mybatis對複雜需求的優化很方便。

4.政治環境

國內好多專案都是應付領導的某些奇葩需求。需要面向領導程式設計。一大半時間其實都是在解決領導的需求。國內專案需要大量報表統計（看看帆軟賣的這麼好就知道了），需要提供給領導作為決策。看到這裡，各位領導不要罵我 ，真的不是黑領導的。

5.Hibernate學習成本高

雖然，實際上SpringDataJPA是非常簡單的，但是，但是，JPA/Hibernate後期除錯跟蹤問題很麻煩，改起來也麻煩。別忘了，牛逼如你的人全公司甚至一個都沒。還有什麼快取什麼Criteria什麼Lazy，雖然這些你學了也不見得能用上，但一個框架，你不學還是不行的。而且，JPA對於增刪改很方便，複雜查詢卻是軟肋，有同學會說，JPA也能寫SQL語句啊，我想說的是，既然都用orm了，你再寫sql，那不就失去了oop的內涵了嗎？不優雅好吧。

四、老外喜歡JPA的原因

1.很多老外對Mybatis的認知還停留在iBatis階段

實際上在Mybatis的應用場景裡面，開發者要的就是自動封裝，把sql查詢結果轉化為指定的java物件。這個在iBatis階段，需要開發者自己定義大量的xml配置，去指定資料庫表欄位與Java實體類之間的關係。並且，對於每一條sql，都需要在xml中寫相應的語句，雖然有程式碼生成器，帶開發量還是不小的。

但Mybatis發展到今天，已經非常完美地做好了自動封裝資料物件這件事，支援的外掛也比較豐富。對於常見的增刪改查，也不需要自己寫一行程式碼，這已經無限接近於Hibernate的能力了。

2.喜歡OOP、DDD，認為寫SQL不優雅

用jpa的核心是讓我們關注物件建模，而不是關心底層資料庫對映。只有你在考慮資料和行為在一起的充血模型、貼身職責，聚合根狀態變遷，值物件不變性的情況下，你才會發現jpa給你提供了很多便利，根本不需要關注底層儲存模型。

在複雜的邏輯、超長的軟體生命週期。使用DDD的設計方法是目前看比較合理的選擇，維護的成本比較低。

DDD全稱是（Domain-Driven Design)這是2004年就出來的理論，複雜邏輯的應對之道。DDD大會在歐洲等地辦了一屆又一屆，CQRS、Event Sourcing等探索層出不窮，這也是為什麼國外比較流行JPA原因。

不過，國內主要是隨著這兩年隨著微服務火爆也有人談起來DDD了。

但其實DDD也不是銀彈，需要大拿能把控全域性，國內缺的就是這種大拿，搬磚的太多。

3.有些老外在技術選型時，不會考慮除Spring這種知名框架外的其他技術

無他，唯手熟爾。國外一個專案，做了幾年十幾年都是很正常的。我以前接觸過一個巴基斯坦的電商專案，做了十幾年，也跑的好好的，這就是證據。

使用技術也是有慣性的。

4.資料體量和種類沒有達到

個人感覺，也諮詢了國際友人。老外的專案，在資料體量和種類上完全達不到國內的水平。所以，他們對於效能上的渴求度沒有那麼高。追求的是穩定，可維護性好。國內一個雙11，如果用hibernate，那隻能死掉了。

也說明，老外的需求主要是在業務上，技術層面較少考慮。

五、一點感悟

整個狀況，和對OOAD的重視有很大關係，我在做DDD技術落地的時候，用MyBatis非常蹩腳，用JPA/Hibernate會好很多。

JPA/Hibernate比較複雜，團隊中要有人Hold住它，否則及其容易踩坑；另外，真要使用，建議使用它的一個功能子集，不要所有功能都用。也可以嘗試使用更簡單EBean ORM。

JPA/Hibernate對分庫分表的支援有一下坑。雖然，使用Shareding-JDBC或MyCat等技術，可以不關心分庫分表，但是，JPA/Hibernate在某些情況下（比如載入子集合的時候）可能會不帶分割槽鍵。國外分庫分表的少，國內幾乎是標配。

六、Mybatis和JPA大比較

最後，從多維度對這兩個知名框架做些比較：

最後的最後，歡迎在評論區留下你最寶貴的意見 ，勿噴哦！

 

參考資料：

1. https://www.zhihu.com/question/50729231/answer/549761974