mybatis和hibernate的對比

首先要明白，在國内的程式設計比較注重的是面向表結構來程式設計的，這是由于國内的大廠中的環境比較注重業務更新速度快，在面向表結構程式設計中，即使業務更新速度快也能不太影響表的設計，不需要重新設計表結構，這樣能夠提高開發效率。而歐美的國家比較注重是面向對象程式設計（雖然說java就是面向對象程式設計）。這就是在國内使用mybatis比較多，而歐美的國家使用hibernate的原因。

開發速度上的對比：

Hibernate的真正掌握要比Mybatis難些。

Mybatis架構相對簡單很容易上手,但也相對簡陋些。

比起兩者的開發速度,不僅僅要考慮到兩者的特性及性能,更要根據項目需求去考慮究竟哪一個更适合項目開發,比如:一個項目中用到的複雜查詢基本沒有,就是簡單的增删改查,這樣選擇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的二級緩存配置在SessionFactory生成的配置檔案中進行詳細配置,然後再在具體的表-對象映射中配置是哪種緩存。

MyBatis的二級緩存配置都是在每個具體的表-對象映射中進行詳細配置,這樣針對不同的表可以自定義不同的緩存機制。并且Mybatis可以在命名空間中共享相同的緩存配置和執行個體,通過Cache-ref來實作。

兩者比較:

因為Hibernate對查詢對象有着良好的管理機制,使用者無需關心SQL。是以在使用二級緩存時如果出現髒資料,系統會報出錯誤并提示。

而MyBatis在這一方面,使用二級緩存時需要特别小心。如果不能完全确定資料更新操作的波及範圍,避免Cache的盲目使用。否則,髒資料的出現會給系統的正常運作帶來很大的隐患。

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

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

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

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