關於SQL 和 ORM 的爭論，永遠都不會終止，我也一直在思考這個問題。昨天又跟群裡的小夥伴進行了一番討論，感觸還是有一些，於是就有了今天這篇文。
聲明：本文不會下關於 Mybatis 和 JPA 兩個持久層框架哪個更好這樣的結論。只是擺事實，講道理，所以，請各位看官勿噴。
一、事件起因
關於 Mybatis 和 JPA 孰優孰劣的問題，爭論已經很多年了。一直也沒有結論，畢竟每個人的喜好和習慣是大不相同的。
我也看過知乎上一些問答，各有各的理由，感覺都挺有道理。如果讓我不帶感情色彩地去分辨，其實我也是懵的，因為真的是公說公有理婆說婆有理。
而在國內，不得不承認，用 Mybatis 的公司確實是要比用 JPA 的多，但是在 2015 年以前，用 Hibernate 的公司確實也是很多的。
為什麼在國內，會有這樣的現象發生？而在國外，老外會一如既往地使用 JPA 呢？我們來分析分析。
二、目前生態
在最近（2018）的 JVM 生態報告中（https://snyk.io/blog/jvm-ecosystem-report-2018-platform-application/），Mybatis是使用率是很低的。可以看圖：
可以看出，Mybatis 的佔比只有可憐的 6%，大家看到這個統計結果應該會很吃驚，你會覺得，不對啊，我公司以及我很多朋友都在用 Mybatis 啊，好像沒聽說過有人用 JPA 的，這個統計結果是錯的吧？
再從下面這個對比來看，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、Hibernate、Spring Data JPA 的關係
而且，JPA 對於增刪改很方便，複雜查詢卻是軟肋，有同學會說，JPA 也能寫 SQL 語句啊，我想說的是，既然都用 orm 了，你再寫 sql，那不就失去了 oop 的內涵了嗎？不優雅好吧。
四、老外喜歡 JPA 的原因
1.很多老外對 Mybatis 的認知還停留在 iBatis 階段
實際上在 Mybatis 的應用場景裡面，開發者要的就是自動封裝，把 sql 查詢結果轉化為指定的 java 對象。
這個在 iBatis 階段，需要開發者自己定義大量的 xml 配置，去指定數據庫表字段與 Java 實體類之間的關係。並且，對於每一條 sql，都需要在 xml 中寫相應的語句，雖然有代碼生成器，帶開發量還是不小的。
但 Mybatis 發展到今天，已經非常完美地做好了自動封裝數據對象這件事，支持的插件也比較豐富。對於常見的增刪改查，也不需要自己寫一行代碼，這已經無限接近於 Hibernate 的能力了。
推薦閱讀：為什麼老外都不願意用MyBatis？
2.喜歡 OOP、DDD
認為寫 SQL 不優雅，用 jpa 的核心是讓我們關注對象建模，而不是關心底層數據庫映射。只有你在考慮數據和行為在一起的充血模型、貼身職責，聚合根狀態變遷，值對象不變性的情況下，你才會發現 jpa 給你提供了很多便利，根本不需要關注底層存儲模型。
在複雜的邏輯、超長的軟件生命週期。使用 DDD 的設計方法是目前看比較合理的選擇，維護的成本比較低。
DDD 全稱是（Domain-Driven Design)這是 2004 年就出來的理論，複雜邏輯的應對之道。DDD 大會在歐洲等地辦了一屆又一屆，CQRS、Event Sourcing 等探索層出不窮，這也是為什麼國外比較流行 JPA 原因。
不過，國內主要是隨著這兩年隨著微服務火爆也有人談起來 DDD 了。但其實 DDD 也不是銀彈，需要大拿能把控全局，國內缺的就是這種大拿，搬磚的太多。
3.有些老外在技術選型時，不會考慮除 Spring 這種知名框架外的其他技術，無他，唯手熟爾。
Spring確實很強，我也寫了 N 篇最新 Spring 教程，關注微信公眾號：Java技術棧，在後臺回覆：spring，可以獲取，都是乾貨。
國外一個項目，做了幾年十幾年都是很正常的。我以前接觸過一個國外的的電商項目，做了十幾年，也跑的好好的，這就是證據。
使用技術也是有慣性的。
4.數據體量和種類沒有達到
個人感覺，也諮詢了國際友人。老外的項目，在數據體量和種類上完全達不到國內的水平。
所以，他們對於性能上的渴求度沒有那麼高。追求的是穩定，可維護性好。國內一個雙 11，如果用 hibernate，那隻能死掉了。
推薦閱讀：淘寶千萬併發，14 次架構演進…
也說明，老外的需求主要是在業務上，技術層面較少考慮。
五、一點感悟
整個狀況，和對 OOAD 的重視有很大關係，我在做 DDD 技術落地的時候，用 MyBatis 非常蹩腳，用 JPA/Hibernate 會好很多。
JPA/Hibernate 比較複雜，團隊中要有人 Hold 住它，否則及其容易踩坑；另外，真要使用，建議使用它的一個功能子集，不要所有功能都用。也可以嘗試使用更簡單 EBean ORM。
JPA/Hibernate 對分庫分表的支持有一下坑。雖然，使用 Shareding-JDBC 或 MyCat 等技術，可以不關心分庫分表，但是，JPA/Hibernate 在某些情況下（比如加載子集合的時候）可能會不帶分區鍵。國外分庫分表的少，國內幾乎是標配。
六、Mybatis 和 JPA 大比較
最後，從多維度對這兩個知名框架做些比較：
最後的最後，歡迎在評論區留下你最寶貴的意見 ，勿噴哦！
閱讀更多 Java的小本家 的文章
