ibatis

iBATIS提供的持久層框架包括SQL Maps和Data Access Objects（DAO），同時還提供一個利用這個框架開發的JPetStore實例。

相對Hibernate和ApacheOJB等“一站式”ORM解決方案而言，ibatis 是一種“半自動化”的ORM實現。

iBATIS 提供了三種語言實現的版本，包括：Java、.NET以及Ruby。圖1是iBATIS的架構圖：

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

大多數情況下（特別是對新項目，新系統的開發而言），這樣的機制無往不利，大有一統天下的勢頭。但是，在一些特定的環境下，這種一站式的解決方案卻未必靈光。

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

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

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

3． 系統數據處理量巨大，性能要求極為苛刻，這往往意味着我們必須通過經過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。

面對這樣的需求，再次舉起 Hibernate 大刀，卻發現刀鋒不再鋭利，甚至無法使用，奈何？恍惚之際，只好再摸出JDBC 準備拼死一搏……，説得未免有些淒涼，直接使用 JDBC進行數據庫操作實際上也是不錯的選擇，只是拖沓的數據庫訪問代碼，乏味的字段讀取操作令人厭煩。

“半自動化”的ibatis，卻剛好解決了這個問題。這裏的“半自動化”，是相對Hibernate等提供了全面的數據庫封裝機制的“全自動化”ORM 實現而言，“全自動”ORM 實現了 POJO 和數據庫表之間的映射，以及 SQL 的自動生成和執行。而ibatis 的着力點，則在於POJO 與 SQL之間的映射關係。也就是説，ibatis並不會為程序員在運行期自動生成 SQL 執行。具體的 SQL 需要程序員編寫，然後通過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定 POJO。

通常在如下場景和條件下，選擇ibatis, 將更有助於發揮ibatis在持久層的優越性：

1. 知道怎樣操作10種以上的數據庫

2. 可配置的caching(包括從屬)

3. 支持DataSource、local transaction management和global transaction

4. 簡單的XML配置文檔

5. 支持Map, Collection, List和簡單類型包裝(如Integer, String)

6. 支持JavaBeans類(get/set 方法)

7. 支持複雜的對象映射(如populating lists, complex object models)

8.對象模型從不完美(不需要修改)

9. 數據模型從不完美(不需要修改)

10. 你已經知道SQL，為什麼還要學習其他東西

使用ibatis 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的 Java對象，

這一層與通過 Hibernate 實現 ORM 而言基本一致，而對於具體的數據操作，Hibernate

會自動生成SQL 語句，而ibatis 則要求開發者編寫具體的 SQL 語句。相對Hibernate等

“全自動”ORM機制而言，ibatis 以 SQL開發的工作量大和數據庫移植性上差為代價，為系統

設計提供了更大的自由空間。作為“全自動”ORM實現的一種有益補充，ibatis 的出現顯

得別具意義。

ibatis本是apache的一個開源項目，2010年這個項目由apache software foundation 遷移到了google code，並且改名為mybatis。