為啥國人偏愛 Mybatis，而老外喜歡 Hibernate/JPA 呢？

作者：佚名 2020-01-08 15:31:41

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

聲明：本文不會下關(guān)于 Mybatis 和 JPA 兩個持久層框架哪個更好這樣的結(jié)論。只是擺事實，講道理，所以，請各位看官勿噴。

一、事件起因

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

而在國內(nèi)，不得不承認，到今年( 2019 年)，用 Mybatis 的公司確實是要比用 JPA 的多，但是在 2015 年以前，用 Hibernate 的公司確實也是很多的。為什么在國內(nèi)，會有這樣的現(xiàn)象發(fā)生?而在國外，老外會一如既往地使用 JPA 呢?我們來分析分析。

二、目前生態(tài)

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

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

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

????

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

首先，必須指出，對于青年程序員，其實都會質(zhì)疑這個圖的可信度。中老年程序員都在感嘆國外其實更注重開發(fā)效率和面向?qū)ο蟮姆治龊驮O(shè)計。但我可以非常負責(zé)任地告訴你，這圖是真的。那么，造成這種現(xiàn)象的原因是?

三、國人喜歡Mybatis的原因

總結(jié)起來，有如下原因：

1.大廠帶節(jié)奏

國內(nèi)做互聯(lián)網(wǎng)的 Java 程序很多都是拷貝阿里的，阿里一開始用例iBatis (日本韓國是怎么回事呢)。大量的老系統(tǒng)都是基于 iBatis/MyBatis 的，市場上對 MyBatis 熟悉的人才更多，招聘和培訓(xùn)更容易，有的青年程序員以為“ MyBatis 早已統(tǒng)一全球了”就是一個很好的證明。

2.簡單，學(xué)習(xí)成本低

小公司需要大量入門級的程序員，像大神甚至一個都請不起，請問大神們那些牛 b 框架哪個更快讓菜鳥們上手，降低公司學(xué)習(xí)成本。注意這個成本會一直跟隨公司，想必大神們創(chuàng)業(yè)直接前后端分離了，畢竟錢嘛多的是。

3.對于復(fù)雜性需求的靈活性高

國內(nèi)絕大部分項目都是面向表結(jié)構(gòu)編程的，把 java 對象僅當成數(shù)據(jù)容器，查詢和模型變更都設(shè)計在一張表上，所謂業(yè)務(wù)邏輯就是一堆增刪改查的 sql 集合，當然用 mybatis 方便。在邏輯不復(fù)雜，或者你判斷軟件生命周期不會超過一年的時候，直接用表結(jié)構(gòu)編程是最方便快捷的。

國內(nèi)普遍都是分布式，流量和性能決定了需要經(jīng)常進行優(yōu)化，而是用 Mybatis 對復(fù)雜需求的優(yōu)化很方便。

4.政治環(huán)境

國內(nèi)好多項目都是應(yīng)付領(lǐng)導(dǎo)的某些奇葩需求。需要面向領(lǐng)導(dǎo)編程。一大半時間其實都是在解決領(lǐng)導(dǎo)的需求。國內(nèi)項目需要大量報表統(tǒng)計(看看帆軟賣的這么好就知道了)，需要提供給領(lǐng)導(dǎo)作為決策。看到這里，各位領(lǐng)導(dǎo)不要罵我，真的不是黑領(lǐng)導(dǎo)的。

5.Hibernate學(xué)習(xí)成本高

雖然，實際上 SpringDataJPA 是非常簡單的，但是，但是，JPA/Hibernate 后期調(diào)試跟蹤問題很麻煩，改起來也麻煩。別忘了，牛逼如你的人全公司甚至一個都沒。還有什么緩存什么 Criteria 什么 Lazy ，雖然這些你學(xué)了也不見得能用上，但一個框架，你不學(xué)還是不行的。而且， JPA 對于增刪改很方便，復(fù)雜查詢卻是軟肋，有同學(xué)會說，JPA 也能寫 SQL 語句啊，我想說的是，既然都用 orm 了，你再寫 sql ，那不就失去了 oop 的內(nèi)涵了嗎?不優(yōu)雅好吧。

四、老外喜歡JPA的原因

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

實際上在 Mybatis 的應(yīng)用場景里面，開發(fā)者要的就是自動封裝，把sql查詢結(jié)果轉(zhuǎn)化為指定的 java 對象。這個在 iBatis 階段，需要開發(fā)者自己定義大量的 xml 配置，去指定數(shù)據(jù)庫表字段與 Java 實體類之間的關(guān)系。并且，對于每一條 sql，都需要在 xml 中寫相應(yīng)的語句，雖然有代碼生成器，但開發(fā)量還是不小的。

但 Mybatis 發(fā)展到今天，已經(jīng)非常完美地做好了自動封裝數(shù)據(jù)對象這件事，支持的插件也比較豐富。對于常見的增刪改查，也不需要自己寫一行代碼，這已經(jīng)無限接近于 Hibernate 的能力了。

2.喜歡OOP、DDD，認為寫SQL不優(yōu)雅

用 jpa 的核心是讓我們關(guān)注對象建模，而不是關(guān)心底層數(shù)據(jù)庫映射。只有你在考慮數(shù)據(jù)和行為在一起的充血模型、貼身職責(zé)，聚合根狀態(tài)變遷，值對象不變性的情況下，你才會發(fā)現(xiàn) jpa 給你提供了很多便利，根本不需要關(guān)注底層存儲模型。

在復(fù)雜的邏輯、超長的軟件生命周期。使用 DDD 的設(shè)計方法是目前看比較合理的選擇，維護的成本比較低。

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

不過，國內(nèi)主要是隨著這兩年隨著微服務(wù)火爆也有人談起來DDD了。

但其實 DDD 也不是銀彈，需要大拿能把控全局，國內(nèi)缺的就是這種大拿，搬磚的太多。

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

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

使用技術(shù)也是有慣性的。

4.數(shù)據(jù)體量和種類沒有達到

個人感覺，也咨詢了國際友人。老外的項目，在數(shù)據(jù)體量和種類上完全達不到國內(nèi)的水平。所以，他們對于性能上的渴求度沒有那么高。追求的是穩(wěn)定，可維護性好。國內(nèi)一個雙11，如果用 hibernate ，那只能死掉了。

也說明，老外的需求主要是在業(yè)務(wù)上，技術(shù)層面較少考慮。

五、一點感悟

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

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

JPA/Hibernate 對分庫分表的支持有一下坑。雖然，使用 Shareding-JDBC 或 MyCa t等技術(shù)，可以不關(guān)心分庫分表，但是，JPA/Hibernate 在某些情況下(比如加載子集合的時候)可能會不帶分區(qū)鍵。國外分庫分表的少，國內(nèi)幾乎是標配。

六、Mybatis和JPA大比較

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