mybatis和hibernate區別大不大？

01-06

我是新手小白。公司需要springmvc + spring + hibernate整合開發，一些基本工作流程能知道，項目還沒開始入手。網上案例一般都是ssh(struts2+spring+hibernate)或者ssm(springmvc+spring+mybatis)，基本沒有我需要的這三個(springmvc+spring+hibernate)整合的案例，所以想問下hibernate和Mybatis的區別大不大，想找點案例都是struct2+spring+hibernate的，沒有我要的三個整合的，如果差不多，就找普遍的SSH或者SSM先熟悉下，如何

謝邀，區別很大，而且Hibernate的難度遠遠大於Mybatis

本身框架區別比較大，一個主要用hql，一個用sql模板，但是現在用法主要都用spring注入session來調用api，你分開看兩種沒什麼關係的

對於學習只停留於表面的程序員來說，差別很大，因為api都不一樣

對於掌握了方法論的程序員來說，差別並不大

個人體會

H.更注重模型，啥都是模型，一個表一個模型，一組表一個模型，模型，模型，你操作起來就是操作模型，所以開始時候模型沒設計好，後面操作起來就非常繁瑣。優點在於要是出門就設計好了，後面的事就順理成章。並且，這樣也很鍛煉分層能力，不管你持久化是nosql還是啥，模型設計好，就好。其實回顧下H.的歷史也不奇怪，本來也就是重方法年代的產物，所以和重方法是一脈相承的。

再說M.家的事。時間推到敏捷開始盛行的年代，快速迭代成了一個適應不同環境的流派，相對於H.，M.更方便更直接，修改起來成本更低，在需求變更滿天飛的環境下，一個能幾筆就改好上線的框架肯定更受歡迎。

再說點題外話，為啥H.，M.都還在更新，誰也替代不了誰，這個其實就是看工程的外部環境。一個巨型項目，一個需求變更就要掉層皮的項目，需要多方協作的項目，多半還是用H.好點，初期設計好，模型約束強，跑不偏也變不了。之所以感嘆為什麼H.這麼笨拙還在用，是因為只要是開發團隊，都只能管中窺豹，看到其中小部分。小部分當然是用快速的套路好啦。

前幾年H.黨和M.黨還爭執，這幾年大家都懶得扯了。一方面NOSQL，內存型資料庫的崛起讓大家發現原來持久化還能這麼玩，另一方面MYSQL這種關係型資料庫也不是一家獨大，呈現百花齊放的勢態，大家被多個緯度拆分了，第三，隨著計算能力和存儲的價格越來越低，效率黨也漸漸退出舞台，餘下的就是愛用啥用啥的隨性派，和按需分配的技術派，沒啥爭論。

額，作為一個基礎只是和紮實八竿子打不著的人，單說H和M的應用的話。

H其實更適用於某些ERP，對於這些ERP來說，性能不是那麼重要，畢竟不涉及到高並發什麼的，數據的完整性是最重要的，所以，一個表單就是一個表單，多個表單之間可能關聯，但會冗餘欄位，這種情況，開發最順手的肯定是各種表映射對象的H更好使。但一旦碰到複雜的多表，H簡直是。。曾經做一個銷售的系統，大部分都是整單的，然而，我做了一個功能涉及到銷售提成計算，8個表關聯把我噁心的不要不要的，我直接說了，我要寫存儲過程，寫視圖，讓我寫JAVA裡面，你就找別人寫這功能吧。。

至於M，做那種表單比H麻煩點有限，然而，碰到多表，封個BO寫sql就好了，而且有時候顧問去實施，他們很多顧問都是會寫sql的，很多簡單的他們也懶得找我們墨跡，問問我們位置，自己就處理了。

說到底，H是為了簡化程序員的工作量，而簡化必定付出代價，M相對於H，增加了少量工作量，同樣也少付出了一部分代價，具體用什麼，沒有什麼誰好誰不好，關鍵是到底在項目中，哪個最重要。

還有，我覺得你不要陷入某些名詞，比如這是SSH，那是SSM，你只需要知道這些是幹嘛的就好了，你需要的僅僅是去查springmvc整合hibernate，而不是去查ssh，因為在最早，ssh屬於比較特定的就是struts

+spring+hibernate，大概7 8年前ssh叫的太響了，導致現在提到ssh，都固化了。。

你把ssh(struts2+spring+hibernate)里的struts2改成springmvc

或者ssm(springmvc+spring+mybatis)里的mybatis改成hibernate不就行了

改個配置的事

有很長一段時間對mybatis是比較陌生的，只知道與Hibernate一樣是個orm資料庫框架。隨著使用熟練度的增加，發現它與Hibernate區別是非常大的，應當結合不同的情況分析選用。結合至今為止的經驗，總結出以下幾點：

1. hibernate是全自動，而mybatis是半自動。

hibernate完全可以通過對象關係模型實現對資料庫的操作，擁有完整的JavaBean對象與資料庫的映射結構來自動生成sql。而mybatis僅有基本的欄位映射，對象數據以及對象實際關係仍然需要通過手寫sql來實現和管理。

2. hibernate資料庫移植性遠大於mybatis。

hibernate通過它強大的映射結構和hql語言，大大降低了對象與資料庫（oracle、mysql等）的耦合性，而mybatis由於需要手寫sql，因此與資料庫的耦合性直接取決於程序員寫sql的方法，如果sql不具通用性而用了很多某資料庫特性的sql語句的話，移植性也會隨之降低很多，成本很高。

3. hibernate擁有完整的日誌系統，mybatis則欠缺一些。

hibernate日誌系統非常健全，涉及廣泛，包括：sql記錄、關係異常、優化警告、緩存提示、臟數據警告等；而mybatis則除了基本記錄功能外，功能薄弱很多。

4. mybatis相比hibernate需要關心很多細節

hibernate配置要比mybatis複雜的多，學習成本也比mybatis高。但也正因為mybatis使用簡單，才導致它要比hibernate關心很多技術細節。mybatis由於不用考慮很多細節，開發模式上與傳統jdbc區別很小，因此很容易上手並開發項目，但忽略細節會導致項目前期bug較多，因而開發出相對穩定的軟體很慢，而開發出軟體卻很快。hibernate則正好與之相反。但是如果使用hibernate很熟練的話，實際上開發效率絲毫不差於甚至超越mybatis。

5. sql直接優化上，mybatis要比hibernate方便很多

由於mybatis的sql都是寫在xml里，因此優化sql比hibernate方便很多。而hibernate的sql很多都是自動生成的，無法直接維護sql；雖有hql，但功能還是不及sql強大，見到報表等變態需求時，hql也歇菜，也就是說hql是有局限的；hibernate雖然也支持原生sql，但開發模式上卻與orm不同，需要轉換思維，因此使用上不是非常方便。總之寫sql的靈活度上hibernate不及mybatis。

隨著使用情況的不斷增多，我又做了進一步的總結總結：

mybatis：小巧、方便、高效、簡單、直接、半自動

hibernate：強大、方便、高效、複雜、繞彎子、全自動

mybatis：

1. 入門簡單，即學即用，提供了資料庫查詢的自動對象綁定功能，而且延續了很好的SQL使用經驗，對於沒有那麼高的對象模型要求的項目來說，相當完美。

2. 可以進行更為細緻的SQL優化，可以減少查詢欄位。

3. 缺點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了數據綁定代碼，但是整個底層資料庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應快速資料庫修改。

4. 二級緩存機制不佳。

hibernate：

1. 功能強大，資料庫無關性好，O/R映射能力強，如果你對Hibernate相當精通，而且對Hibernate進行了適當的封裝，那麼你的項目整個持久層代碼會相當簡單，需要寫的代碼很少，開發速度很快，非常爽。

2. 有更好的二級緩存機制，可以使用第三方緩存。

3. 缺點就是學習門檻不低，要精通門檻更高，而且怎麼設計O/R映射，在性能和對象模型之間如何權衡取得平衡，以及怎樣用好Hibernate方面需要你的經驗和能力都很強才行。

舉個形象的比喻：

mybatis：機械工具，使用方便，拿來就用，但工作還是要自己來作，不過工具是活的，怎麼使由我決定。

hibernate：智能機器人，但研發它（學習、熟練度）的成本很高，工作都可以擺脫他了，但僅限於它能做的事。

不怎麼大，h稍微難一點，但是m比較靈活，調優什麼的也比較簡單但是要自己寫

只要你會這三個框架，難度就不大，而且你要知道，框架的整合一般都是兩兩整合，也就是和spring整合。

一個簡單封裝，一個深度封裝，一個更接近sql，一個更接近對象

為什麼要糾結框架呢，那只是工具而已，稍微理解下內在的東西這種Object Relational Mapping框架用起來都不難，多往底層看看學學，會收穫很大。

好吧，我真的想吐槽一下那個hibernate，各種模板還得hql，為了面向對象增加很多概念，搞不懂全orm這樣子有什麼好的，控制顆粒度不夠好我覺得

而mybatis呢，插件生成代碼，顆粒度sql你輕鬆控制，而且還有example模板給你用，簡直好得不得了，用起來也很清晰，所以強力覺得mybatis的這種半orm well done

同新手。本來想說用起來都很簡單，看到前面大神們的回復，我開始覺得我還沒入門了。

hibernate真的重，雖然關聯比較坑，主要是ORM設計論沒弄明白，其實還好，至於Mybatis這個東西，短平快，暴力解決問題，總有一天會因為一堆映射xml而崩潰的

個人覺得可以不用搞hibernate,趨勢是自由和便捷,使用hibernate開發起來快速,也不用寫sql,但涉及到業務變化的時候,需要做的改動較大.

區別特別大，hibernate的難度大概是3個mybatis

hibernate原意：冬眠。僅僅是單表映射，對象化。這兩者沒什麼區別，你還會覺得mybatis還要TM自己寫sql，垃圾。

同學，當要玩多表關聯的時候。你會8成會去冬眠的，hibernate處理多表關聯關係簡直如噩夢一般。這個時候你會想念mybatis手寫sql了。

mybatis對於開發者，自由度更大。我個人也更喜歡用mybatis。

不管hibernate、mybatis只是完成一個數據層對象化，方便coding。MVC模式只是完成這個model的作用。具體用什麼從實際需求，個人喜好選擇。不必擔心會有什麼不搭配的問題。各個框架集成的時候注意配置文件。

區別還是有點大的，兩種不太一樣的模式。但是都沒什麼難度

差別還是蠻大的，我現在就在做一個WMS的項目（SpringMvc + Spring + hibernate）前台用的基於Bootstrap的Metronic

最近在用 Hibernate，超噁心。。。查個數據寫 HQL 要來來回回好多句。。。反倒浪費了時間。

Mybatis 靈活多了，現成的用不了自己寫個 SQL 語句啊，直接在 MySQL 的控制台上做實驗，語句通過了再放代碼里就好。。。HQL 的不能，有時候語句錯一點就搞半天簡直了。。。

當然，大佬們一定會說哎呀都簡單，呵呵噠！

========【一個月後】========

哎呀這 Hibernate 怎麼這麼好用啊哈哈哈哈！

你看你看，存對象寫個 save 就好了呀！

啥？你說寫語句？不存在的好嘛。