關于 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 或 MyCa t等技術，可以不關心分庫分表，但是，JPA/Hibernate 在某些情況下(比如加載子集合的時候)可能會不帶分區鍵。國外分庫分表的少，國內幾乎是標配。

六、Mybatis和JPA大比較

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

??

??

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

參考資料：

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

趨勢圖來源：https://trends.google.com/trends/explore?q=%2Fm%2F04t80p,MyBatis

責編：保安隊長

配圖：貓仙大人