ibatis和hibernate的比較

  ibatis和hibernate的比較 收藏

IBATIS:

iBATIS一詞來源於“internet”和“abatis”的組合，是一個由Clinton Begin在2001年發起的開放源代碼項目，最初側重於密碼軟件的開發，現在是一個基於Java的持久層框架。

iBATIS提供的持久層框架包括SQL Maps和Data Access Objects（DAO），同時還提供一個利用這個框架開發的JPetStore實例，相對Hibernate和Apache OJB等“一站式”ORM解決方案而言，ibatis 是一種“半自動化”的ORM實現，iBATIS需要開發人員自己來寫sql語句，這可以增加了程序的靈活性，在一定程度上可以作爲ORM的一種補充，程序 設計人員應該結合自己的項目的實際情況，來選擇使用不同的策略。

iBATIS和Hibernate都做了映射，但iBATIS是把實體類和sql語句之間建立了映射關係，這種策略可以允許開發人員自己來寫合 適的sql語句，而Hibernate在實體類和數據庫之間建立了映射關係，sql對於開發人員是不可見的，對於那些數據量非常大的應用，無法去優化 sql語句。

所謂“半自動”，可能理解上有點生澀,縱觀目前主流的ORM，無論Hibernate還是Apache OJB，都對數據庫結構提供了較爲完整的封裝，提供了從POJO到數據庫表的全套映射機制,程序員往往只需定義好了POJO到數據庫表的映射關係，即可通 過 Hibernate或者 OJB 提供的方法完成持久層操作,程序員甚至不需要對 SQL 的熟練掌握， Hibernate/OJB 會根據制定的存儲邏輯，自動生成對應的SQL並調用JDBC接口加以執行。 

HIBERNATE:

Hibernate是一個開放源代碼的對象關係映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫.

Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序使用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成數據持久化的重任.

Hibernate是一個免費的開源Java包，它使得與關係數據庫打交道變得十分輕鬆，就像您的數據庫中包含每天使用的普通Java對象一樣，同時不必考慮如何把它們從神祕的數據庫表中取出（或放回到數據庫表中）

IBATIS和HIBERNATE的比較：

在系統諮詢工作過程中，常常遇到以下情況： 　　

1． 系統的部分或全部數據來自現有數據庫，處於安全考慮，只對開發團隊提供幾條Select SQL（或存儲過程）以獲取所需數據，具體的表結構不予公開

2． 開發規範中要求，所有牽涉到業務邏輯部分的數據庫操作，必須在數據庫層由存儲過程實現（就筆者工作所面向的金融行業而言，工商銀行、中國銀行、交通銀行，都在開發規範中嚴格指定）

3． 系統數據處理量巨大，性能要求極爲苛刻，這往往意味着我們必須通過經過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標，面對這樣的需求，再 次舉起 Hibernate 大刀，卻發現刀鋒不再銳利，甚至無法使用，奈何？恍惚之際，只好再摸出JDBC 準備拼死一搏……，說得未免有些淒涼，直接使用 JDBC進行數據庫操作實際上也是不錯的選擇，只是拖沓的數據庫訪問代碼，乏味的字段讀取操作令人厭煩，“半自動化”的ibatis，卻剛好解決了這個問 題，這裏的“半自動化”，是相對Hibernate等提供了全面的數據庫封裝機制的“全自動化”，ORM 實現而言，“全自動”ORM 實現了 POJO 和數據庫表之間的映射，以及 SQL 的自動生成和執行，而ibatis 的着力點，則在於POJO 與 SQL之間的映射關係，也就是說，ibatis並不會爲程序員在運行期自動生成 SQL 執行，具體的 SQL 需要程序員編寫，然後通過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定 POJO。

　　使用ibatis 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的 Java對象，這一層與通過 Hibernate 實現 ORM 而言基本一致，而對於具體的數據操作，Hibernate會自動生成SQL 語句，而ibatis 則要求開發者編寫具體的 SQL 語句，相對Hibernate等“全自動”ORM機制而言，ibatis 以 SQL開發的工作量和數據庫移植性上的讓步，爲系統設計提供了更大的自由空間，作爲“全自動”ORM實現的一種有益補充，ibatis 的出現顯得別具意義。

IBATIS的優勢：

1. iBatis 易於掌握。拿來文檔看半天到兩天就可以掌握了。

Hibernate 可能需要 3 倍以上的時間來掌握。

2. iBatis 更容易進行 sql 的 優化。

這個應該大家都有共識了。另外 Hibernate 生成的 sql 也實在是太難看了。鑑於有的朋友提到了 sql 不太重要。我想在這裏強調一下我的經驗，一般系統性能的瓶頸都在數據庫上。所以這一點是 iBatis 非常重要的一個優勢。

3. iBatis 可以進行細粒度的優化

3.1 比如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis 很簡單，執行一個sql

UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#但是用 Hibernate 的話就比較麻煩了,缺省的情況下hibernate 會更新所有字段。當然我記得 hibernate 有一個選項可以控制只保存修改過的字段，但是我不太確定這個功能的負面效果。

3.2 我需要列出一個表的部分內容，用 iBatis 的時候，這裏面的好處是可以少從數據庫讀很多數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...

3.2.1 一般情況下，Hibernate 會把所有的字段都選出來。比如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我爲什麼要把他們也選出來呢？

3.2.2 用 hibernate 的話，你又不能把這兩個不需要的字段設置爲 lazy load，因爲還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯現出ibatis 的好處了

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

3.3 如果我需要更新一條記錄（一個對象），如果使用 hibernate，需要現把對象 select 出來，然後再做update。這對數據庫來說就是兩條 sql。而 iBatis只需要一條 update 的 sql 就可以了。減少一次與數據庫的交互，對於性能的提升是非常重要。

4. 開發方面

4.1 開發效率上，我覺得兩者應該差不多

4.2 可維護性方面，我覺得 iBatis 更好一些。因爲 iBatis 的 sql 都保存到單獨的文件中。而 Hibernate 在有些情況下可能會在 java 代碼中保存sql/hql。

5. 運行效率

5.1 在不考慮 cache 的情況下，iBatis 應該會比hibernate 快一些或者很多（根據實際情況會有所不同）。

當然 iBatis 也有比較大的缺點

1. 不同數據庫類型的支持不好，如果你要開發的系統是要在對中數據間移植，那可能用 hibernate 比較好。

2. 缺省的 cache 支持不好，但是 hibernate 的 cache 支持其實也不是很好，而且很複雜。尤其是對於大併發量的應用。所以我更傾向於自己管理 cache。

在實際應用中，應該根據不同的應用場景，來選擇適合自己的框架。