1. 簡介

Hibernate是當(dāng)前最流行的O/R mapping框架。它出身于sf.net，現(xiàn)在已經(jīng)成為Jboss的一部分了。iBATIS是另外一種優(yōu)秀的O/R mapping框架，現(xiàn)已改名叫myBATIS。目前屬于apache的一個子項目了。相對Hibernate"O/R"而言，iBATIS 是一種"Sql Mapping"的ORM實現(xiàn)。

Hibernate對數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，Hibernate的O/R Mapping實現(xiàn)了POJO和數(shù)據(jù)庫表之間的映射，以及SQL的自動生成和執(zhí)行。程序員往往只需定義好了POJO到數(shù)據(jù)庫表的映射關(guān)系，即可通過Hibernate提供的方法完成持久層操作。程序員甚至不需要對SQL的熟練掌握，Hibernate/OJB會根據(jù)制定的存儲邏輯，自動生成對應(yīng)的SQL并調(diào)用JDBC接口加以執(zhí)行。

而iBATIS的著力點，則在于POJO與SQL之間的映射關(guān)系。也就是說，iBATIS并不會為程序員在運行期自動生成SQL執(zhí)行。具體的SQL需要程序員編寫，然后通過映射配置文件，將SQL所需的參數(shù)，以及返回的結(jié)果字段映射到指定POJO。使用iBATIS提供的ORM機制，對業(yè)務(wù)邏輯實現(xiàn)人員而言，面對的是純粹的java對象，這一層與通過Hibernate 實現(xiàn)ORM而言基本一致，而對于具體的數(shù)據(jù)操作，Hibernate會自動生成SQL語句，而iBATIS則要求開發(fā)者編寫具體的SQL語句。相對Hibernate而言，iBATIS以SQL開發(fā)的工作量和數(shù)據(jù)庫移植性上的讓步，為系統(tǒng)設(shè)計提供了更大的自由空間。

2. 二者的對比

1)iBATIS非常簡單易學(xué)，Hibernate相對較復(fù)雜，門檻較高。iBATIS拿來文檔看半天到兩天就可以掌握了。Hibernate可能需要3倍以上的時間來掌握。

2) 二者都是比較優(yōu)秀的開源產(chǎn)品。但Hibernate現(xiàn)在已經(jīng)是主流O/R Mapping框架，從文檔的豐富性，產(chǎn)品的完善性，版本的開發(fā)速度都要強于iBATIS。

3) 當(dāng)系統(tǒng)屬于二次開發(fā)，無法對數(shù)據(jù)庫結(jié)構(gòu)做到控制和修改，那iBATIS的靈活性將比Hibernate更適合。

4) 系統(tǒng)數(shù)據(jù)處理量巨大，性能要求極為苛刻，這往往意味著我們必須通過經(jīng)過高度優(yōu)化的SQL語句（或存儲過程）才能達(dá)到系統(tǒng)性能設(shè)計指標(biāo)。在這種情況下iBATIS會有更好的可控性和表現(xiàn)。iBatis比Hibernate更容易進(jìn)行sql的優(yōu)化。鑒于一般系統(tǒng)性能的瓶頸都在數(shù)據(jù)庫上，所以這一點是iBatis非常重要的一個優(yōu)勢。

5) iBatis 可以進(jìn)行細(xì)粒度的優(yōu)化

• 比如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis很簡單，執(zhí)行一個sql：UPDATE table_a SET column_1=#column_1# WHERE id=#id#但是用Hibernate的話就比較麻煩了，缺省的情況下hibernate會更新所有字段。當(dāng)然，hibernate有一個選項可以控制只保存修改過的字段。
• 我需要列出一個表的部分內(nèi)容，用iBatis的時候，這里面的好處是可以少從數(shù)據(jù)庫讀很多數(shù)據(jù)，節(jié)省流量SELECT id, name FROM table_with_a_lot_of_column WHERE ...
  • 一般情況下Hibernate會把所有的字段都選出來。比如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我為什么要把他們也選出來呢？
  • 用hibernate的話，你又不能把這兩個不需要的字段設(shè)置為lazy load，因為還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯出ibatis的好處了。
  • Hibernate還有一個方案，就是生成javabean/map/object[](感謝leelun/cjmm)，但是這樣的話就可能會產(chǎn)生大量的多余class。map/object[] 的方式應(yīng)該不錯，我比較喜歡這種方式。
• 如果我需要更新一條記錄（一個對象），如果使用hibernate，需要現(xiàn)把對象select出來，然后再做update。這對數(shù)據(jù)庫來說就是兩條sql。而iBatis只需要一條update的sql就可以了。減少一次與數(shù)據(jù)庫的交互，對于性能的提升是非常重要。

6) iBatis需要手寫sql語句，也可以生成一部分，Hibernate則基本上可以自動生成，偶爾會寫一些Hql。同樣的需求，iBATIS的工作量比Hibernate要大很多。類似的，如果涉及到數(shù)據(jù)庫字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。

7) 開發(fā)方面

• 開發(fā)效率上，我覺得兩者應(yīng)該差不多
• 可維護(hù)性方面，我覺得iBatis更好一些。因為iBatis的sql都保存到單獨的文件中。而Hibernate在有些情況下可能會在java代碼中保存sql/hql。

8) 運行效率在不考慮cache的情況下，iBatis應(yīng)該會比hibernate快一些或者很多（根據(jù)實際情況會有所不同）。9) 對不同數(shù)據(jù)庫類型的支持。iBatis對不同數(shù)據(jù)庫類型的支持不夠好，如果你要開發(fā)的系統(tǒng)是要在對中數(shù)據(jù)間移植，那可能用hibernate比較好。

10)對缺省的cache支持。iBatis對缺省的cache支持不夠好，但是hibernate的cache支持其實也不是很好，而且很復(fù)雜。尤其是對于大并發(fā)量的應(yīng)用。所以我更傾向于自己管理cache。

11) 以數(shù)據(jù)庫字段一一對應(yīng)映射得到的PO(persistantobject)和Hibernte這種對象化映射得到的PO是截然不同的，本質(zhì)區(qū)別在于這種PO是扁平化的，不像Hibernate映射的PO是可以表達(dá)立體的對象繼承，聚合等等關(guān)系的，這將會直接影響到你的整個軟件系統(tǒng)的設(shè)計思路。

12) 最關(guān)鍵的一句話是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功能強大，數(shù)據(jù)庫無關(guān)性好，O/R映射能力強，如果你對Hibernate相當(dāng)精通，而且對Hibernate進(jìn)行了適當(dāng)?shù)姆庋b，那么你的項目整個持久層代碼會相當(dāng)簡單，需要寫的代碼很少，開發(fā)速度很快，非常爽。
• Hibernate的缺點就是學(xué)習(xí)門檻不低，要精通門檻更高，而且怎么設(shè)計O/R映射，在性能和對象模型之間如何權(quán)衡取得平衡，以及怎樣用好Hibernate方面需要你的經(jīng)驗和能力都很強才行。
• iBATIS入門簡單，即學(xué)即用，提供了數(shù)據(jù)庫查詢的自動對象綁定功能，而且延續(xù)了很好的SQL使用經(jīng)驗，對于沒有那么高的對象模型要求的項目來說，相當(dāng)完美。
• iBATIS的缺點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了數(shù)據(jù)綁定代碼，但是整個底層數(shù)據(jù)庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應(yīng)快速數(shù)據(jù)庫修改。

原文出處：http://blog.csdn.net/ya2dan/article/details/7396598