HIBERNATE與 MYBATIS的對比

我是一名java開發人員，hibernate以及mybatis都有過學習，在java面試中也被說起問道過，在項目實踐中也應用過，如今對hibernate和mybatis作一下對比，便於你們更好的理解和學習，使本身在作項目中更加駕輕就熟。

第一方面：開發速度的對比

就開發速度而言，Hibernate的真正掌握要比Mybatis來得難些。Mybatis框架相對簡單很容易上手，但也相對簡陋些。我的以爲要用好Mybatis仍是首先要先理解好Hibernate。

比起二者的開發速度，不只僅要考慮到二者的特性及性能，更要根據項目需求去考慮究竟哪個更適合項目開發，好比：一個項目中用到的複雜查詢基本沒有，就是簡單的增刪改查，這樣選擇hibernate效率就很快了，由於基本的sql語句已經被封裝好了，根本不須要你去寫sql語句，這就節省了大量的時間，可是對於一個大型項目，複雜語句較多，這樣再去選擇hibernate就不是一個太好的選擇，選擇mybatis就會加快許多，並且語句的管理也比較方便。

第二方面：開發工做量的對比

Hibernate和MyBatis都有相應的代碼生成工具。能夠生成簡單基本的DAO層方法。針對高級查詢，Mybatis須要手動編寫SQL語句，以及ResultMap。而Hibernate有良好的映射機制，開發者無需關心SQL的生成與結果映射，能夠更專一於業務流程。

第三方面：sql優化方面

Hibernate的查詢會將表中的全部字段查詢出來，這一點會有性能消耗。Hibernate也能夠本身寫SQL來指定須要查詢的字段，但這樣就破壞了Hibernate開發的簡潔性。而Mybatis的SQL是手動編寫的，因此能夠按需求指定查詢的字段。

Hibernate HQL語句的調優須要將SQL打印出來，而Hibernate的SQL被不少人嫌棄由於太醜了。MyBatis的SQL是本身手動寫的因此調整方便。但Hibernate具備本身的日誌統計。Mybatis自己不帶日誌統計，使用Log4j進行日誌記錄。

第四方面：對象管理的對比

Hibernate 是完整的對象/關係映射解決方案，它提供了對象狀態管理（state management）的功能，使開發者再也不須要理會底層數據庫系統的細節。也就是說，相對於常見的 JDBC/SQL 持久層方案中須要管理 SQL 語句，Hibernate採用了更天然的面向對象的視角來持久化 Java 應用中的數據。

換句話說，使用 Hibernate 的開發者應該老是關注對象的狀態（state），沒必要考慮 SQL 語句的執行。這部分細節已經由 Hibernate 掌管穩當，只有開發者在進行系統性能調優的時候才須要進行了解。而MyBatis在這一塊沒有文檔說明，用戶須要對對象本身進行詳細的管理。
第五方面：緩存機制

Hibernate緩存

Hibernate一級緩存是Session緩存，利用好一級緩存就須要對Session的生命週期進行管理好。建議在一個Action操做中使用一個Session。一級緩存須要對Session進行嚴格管理。

Hibernate二級緩存是SessionFactory級的緩存。 SessionFactory的緩存分爲內置緩存和外置緩存。內置緩存中存放的是SessionFactory對象的一些集合屬性包含的數據(映射元素據及預約SQL語句等),對於應用程序來講,它是隻讀的。外置緩存中存放的是數據庫數據的副本,其做用和一級緩存相似.二級緩存除了之內存做爲存儲介質外,還能夠選用硬盤等外部存儲設備。二級緩存稱爲進程級緩存或SessionFactory級緩存，它能夠被全部session共享，它的生命週期伴隨着SessionFactory的生命週期存在和消亡。

MyBatis緩存

MyBatis 包含一個很是強大的查詢緩存特性,它能夠很是方便地配置和定製。MyBatis 3 中的緩存實現的不少改進都已經實現了,使得它更增強大並且易於配置。

默認狀況下是沒有開啓緩存的,除了局部的 session 緩存,能夠加強變現並且處理循環 依賴也是必須的。要開啓二級緩存,你須要在你的 SQL 映射文件中添加一行:  <cache/>

字面上看就是這樣。這個簡單語句的效果以下:

1. 映射語句文件中的全部 select 語句將會被緩存。

2. 映射語句文件中的全部 insert,update 和 delete 語句會刷新緩存。

3. 緩存會使用 Least Recently Used(LRU,最近最少使用的)算法來收回。

4. 根據時間表(好比 no Flush Interval,沒有刷新間隔), 緩存不會以任什麼時候間順序 來刷新。

5. 緩存會存儲列表集合或對象(不管查詢方法返回什麼)的 1024 個引用。

6. 緩存會被視爲是 read/write(可讀/可寫)的緩存,意味着對象檢索不是共享的,而 且能夠安全地被調用者修改,而不干擾其餘調用者或線程所作的潛在修改。

全部的這些屬性均可以經過緩存元素的屬性來修改。

好比: <cache  eviction=」FIFO」  flushInterval=」60000″  size=」512″  readOnly=」true」/>

這個更高級的配置建立了一個 FIFO 緩存,並每隔 60 秒刷新,存數結果對象或列表的 512 個引用,並且返回的對象被認爲是隻讀的,所以在不一樣線程中的調用者之間修改它們會 致使衝突。可用的收回策略有, 默認的是 LRU:

1. LRU – 最近最少使用的:移除最長時間不被使用的對象。

2. FIFO – 先進先出:按對象進入緩存的順序來移除它們。

3. SOFT – 軟引用:移除基於垃圾回收器狀態和軟引用規則的對象。

4. WEAK – 弱引用:更積極地移除基於垃圾收集器狀態和弱引用規則的對象。

flushInterval(刷新間隔)能夠被設置爲任意的正整數,並且它們表明一個合理的毫秒 形式的時間段。默認狀況是不設置,也就是沒有刷新間隔,緩存僅僅調用語句時刷新。

size(引用數目)能夠被設置爲任意正整數,要記住你緩存的對象數目和你運行環境的 可用內存資源數目。默認值是1024。

readOnly(只讀)屬性能夠被設置爲 true 或 false。只讀的緩存會給全部調用者返回緩 存對象的相同實例。所以這些對象不能被修改。這提供了很重要的性能優點。可讀寫的緩存 會返回緩存對象的拷貝(經過序列化) 。這會慢一些,可是安全,所以默認是 false。

相同點：Hibernate和Mybatis的二級緩存除了採用系統默認的緩存機制外，均可以經過實現你本身的緩存或爲其餘第三方緩存方案，建立適配器來徹底覆蓋緩存行爲。

不一樣點：Hibernate的二級緩存配置在SessionFactory生成的配置文件中進行詳細配置，而後再在具體的表-對象映射中配置是那種緩存。

MyBatis的二級緩存配置都是在每一個具體的表-對象映射中進行詳細配置，這樣針對不一樣的表能夠自定義不一樣的緩存機制。而且Mybatis能夠在命名空間中共享相同的緩存配置和實例，經過Cache-ref來實現。

二者比較：由於Hibernate對查詢對象有着良好的管理機制，用戶無需關心SQL。因此在使用二級緩存時若是出現髒數據，系統會報出錯誤並提示。

而MyBatis在這一方面，使用二級緩存時須要特別當心。若是不能徹底肯定數據更新操做的波及範圍，避免Cache的盲目使用。不然，髒數據的出現會給系統的正常運行帶來很大的隱患。

第六方面：總結

對於總結，你們能夠到各大java論壇去看一看

相同點：Hibernate與MyBatis均可以是經過SessionFactoryBuider由XML配置文件生成SessionFactory，而後由SessionFactory 生成Session，最後由Session來開啓執行事務和SQL語句。其中SessionFactoryBuider，SessionFactory，Session的生命週期都是差很少的。

• Hibernate和MyBatis都支持JDBC和JTA事務處理。

Mybatis優點

• MyBatis能夠進行更爲細緻的SQL優化，能夠減小查詢字段。

• MyBatis容易掌握，而Hibernate門檻較高。

Hibernate優點

• Hibernate的DAO層開發比MyBatis簡單，Mybatis須要維護SQL和結果映射。

• Hibernate對對象的維護和緩存要比MyBatis好，對增刪改查的對象的維護要方便。

• Hibernate數據庫移植性很好，MyBatis的數據庫移植性很差，不一樣的數據庫須要寫不一樣SQL。

• Hibernate有更好的二級緩存機制，可使用第三方緩存。MyBatis自己提供的緩存機制不佳。

他人總結

• Hibernate功能強大，數據庫無關性好，O/R映射能力強，若是你對Hibernate至關精通，並且對Hibernate進行了適當的封裝，那麼你的項目整個持久層代碼會至關簡單，須要寫的代碼不多，開發速度很快，很是爽。

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

• iBATIS入門簡單，即學即用，提供了數據庫查詢的自動對象綁定功能，並且延續了很好的SQL使用經驗，對於沒有那麼高的對象模型要求的項目來講，至關完美。

• iBATIS的缺點就是框架仍是比較簡陋，功能尚有缺失，雖然簡化了數據綁定代碼，可是整個底層數據庫查詢實際仍是要本身寫的，工做量也比較大，並且不太容易適應快速數據庫修改。