這是一篇很不錯的文章,長見識,文章有點長,你們能夠慢慢讀。會有所收穫的。java
關於SQL 和 ORM 的爭論,永遠都不會終止,我也一直在思考這個問題。昨天又跟羣裏的小夥伴進行了一番討論,感觸仍是有一些,因而就有了今天這篇文。程序員
聲明:面試
本文不會下關於 Mybatis 和 JPA 兩個持久層框架哪一個更好這樣的結論。只是擺事實,講道理,因此,請各位看官勿噴。spring
關於 Mybatis 和 JPA 孰優孰劣的問題,爭論已經不少年了。一直也沒有結論,畢竟每一個人的喜愛和習慣是大不相同的。sql
我也看過知乎上一些問答,各有各的理由,感受都挺有道理。若是讓我不帶感情色彩地去分辨,其實我也是懵的,由於真的是公說公有理婆說婆有理。數據庫
而在國內,不得不認可,用 Mybatis 的公司確實是要比用 JPA 的多,可是在 2015 年之前,用 Hibernate 的公司確實也是不少的。編程
爲何在國內,會有這樣的現象發生?而在國外,老外會一如既往地使用 JPA 呢?咱們來分析分析。後端
在最近(2018)的 JVM 生態報告中(https://snyk.io/blog/jvm-ecosystem-report-2018-platform-application/),Mybatis是使用率是很低的。能夠看圖:緩存
能夠看出,Mybatis 的佔比只有可憐的 6%,你們看到這個統計結果應該會很吃驚,你會以爲,不對啊,我公司以及我不少朋友都在用 Mybatis 啊,好像沒據說過有人用 JPA 的,這個統計結果是錯的吧?微信
再從下面這個對比來看,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 的內涵了嗎?不優雅好吧。
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 在某些狀況下(好比加載子集合的時候)可能會不帶分區鍵。國外分庫分表的少,國內幾乎是標配。
最後,從多維度對這兩個知名框架作些比較:
最後的最後,歡迎在評論區留下你最寶貴的意見 ,勿噴哦!
最後的最後,關於這個話題,你怎麼看待的?歡迎在底部留言!
參考:zhihu.com/question/50729231/answer/549761974
來源:blog.csdn.net/m0_37609579/article/details/102961765
推薦去個人博客閱讀更多:
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
以爲不錯,別忘了點贊+轉發哦!