IBatis和Hibernate區別

原文出處：http://www.cnblogs.com/mingyongcheng/p/3588100.html

IBatis和Hibernate區別

 

1. 簡介

Hibernate是當前最流行的O/R mapping框架。它出身於sf.net，如今已經成爲Jboss的一部分了。iBATIS是另一種優秀的O/R mapping框架，現已更名叫myBATIS。目前屬於apache的一個子項目了。相對Hibernate"O/R"而言，iBATIS 是一種"Sql Mapping"的ORM實現。

Hibernate對數據庫結構提供了較爲完整的封裝，Hibernate的O/R Mapping實現了POJO和數據庫表之間的映射，以及SQL的自動生成和執行。程序員每每只需定義好了POJO到數據庫表的映射關係，便可經過 Hibernate提供的方法完成持久層操做。程序員甚至不須要對SQL的熟練掌握，Hibernate/OJB會根據制定的存儲邏輯，自動生成對應的 SQL並調用JDBC接口加以執行。

而iBATIS的着力點，則在於POJO與SQL之間的映射關係。也就是說，iBATIS並不會爲程序員在運行期自動生成SQL執行。具體的SQL須要程 序員編寫，而後經過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。使用iBATIS提供的ORM機制，對業務邏輯實現人員而 言，面對的是純粹的Java對象，這一層與經過Hibernate 實現ORM而言基本一致，而對於具體的數據操做，Hibernate會自動生成SQL語句，而iBATIS則要求開發者編寫具體的SQL語句。相對 Hibernate而言，iBATIS以SQL開發的工做量和數據庫移植性上的讓步，爲系統設計提供了更大的自由空間。

2. 兩者的對比

1)iBATIS很是簡單易學，Hibernate相對較複雜，門檻較高。iBATIS拿來文檔看半天到兩天就能夠掌握了。Hibernate可能須要3倍以上的時間來掌握。

2) 兩者都是比較優秀的開源產品。但Hibernate如今已是主流O/R Mapping框架，從文檔的豐富性，產品的完善性，版本的開發速度都要強於iBATIS。

3) 當系統屬於二次開發，沒法對數據庫結構作到控制和修改，那iBATIS的靈活性將比Hibernate更適合。

4) 系統數據處理量巨大，性能要求極爲苛刻，這每每意味着咱們必須經過通過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。在這種狀況下iBATIS會有更好的可控性和表現。iBatis比Hibernate更容易進行sql的優化。鑑於通常系統性能的瓶頸都在數據庫上，因此這一點是iBatis很是重要的一個優點。

5) iBatis 能夠進行細粒度的優化

• 好比說我有一個表，這個表有幾個或者幾十個字段，我須要更新其中的一個字段，iBatis很簡單，執行一個sql：UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 可是用Hibernate的話就比較麻煩了，缺省的狀況下hibernate會更新全部字段。固然，hibernate有一個選項能夠控制只保存修改過的字段。

• 我須要列出一個表的部份內容，用iBatis的時候，這裏面的好處是能夠少從數據庫讀不少數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...

  • 通常狀況下Hibernate會把全部的字段都選出來。好比說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我爲何要把他們也選出來呢？

  • 用hibernate的話，你又不能把這兩個不須要的字段設置爲lazy load，由於還有不少地方須要一次把整個 domain object 加載出來。這個時候就能顯出ibatis的好處了。

  • Hibernate還有一個方案，就是生成javabean/map/object[](感謝leelun/cjmm)，可是這樣的話就可能會產生大量的多餘class。map/object[] 的方式應該不錯，我比較喜歡這種方式。

• 若是我須要更新一條記錄（一個對象），若是使用hibernate，須要現把對象select出來，而後再作update。這對數據庫來講就是兩條 sql。而iBatis只須要一條update的sql就能夠了。減小一次與數據庫的交互，對於性能的提高是很是重要。

6) iBatis須要手寫sql語句，也能夠生成一部分，Hibernate則基本上能夠自動生成，偶爾會寫一些Hql。一樣的需求，iBATIS的工做量比Hibernate要大不少。相似的，若是涉及到數據庫字段的修改，Hibernate修改的地方不多，而iBATIS要把那些sql mapping的地方一一修改。

7) 開發方面 

• 開發效率上，我以爲二者應該差很少 

• 可維護性方面，我以爲iBatis更好一些。由於iBatis的sql都保存到單獨的文件中。而Hibernate在有些狀況下可能會在java代碼中保存sql/hql。

8)  運行效率 
在不考慮cache的狀況下，iBatis應該會比hibernate快一些或者不少（根據實際狀況會有所不一樣）。 
9) 對不一樣數據庫類型的支持。iBatis對不一樣數據庫類型的支持不夠好，若是你要開發的系統是要在對中數據間移植，那可能用hibernate比較好。 

10)對缺省的cache支持。iBatis對缺省的cache支持不夠好，可是hibernate的cache支持其實也不是很好，並且很複雜。尤爲是對於大併發量的應用。因此我更傾向於本身管理cache。

11) 以數據庫字段一一對應映射獲得的PO(persistant object)和Hibernte這種對象化映射獲得的PO是大相徑庭的，本質區別在於這種PO是扁平化的，不像Hibernate映射的PO是能夠表達立體的對象繼承，聚合等等關係的，這將會直接影響到你的整個軟件系統的設計思路。

12) 最關鍵的一句話是iBATIS的做者說的：If you are starting a new project and you're in full control of your object model and database design, Hibernate is a good choice of O/R tool.If you are accessing any 3rd party databases (e.g. vendor supplied), or you're working with a legacy database, or even just a really poorly designed database, then an O/R mapper might not be capable of handling the situation. That's were an SQL Mapper comes in handy

3. 如何選擇

選擇Hibernate仍是iBATIS都有它的道理： 

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

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

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

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