古詩詞大全網 - 成語用法 - ibatis和hibernate的區別

ibatis和hibernate的區別

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