iBATIS一詞來源於“internet”和“abatis”的組合，是一個由Clinton Begin在2001年發起的開放原始碼專案。最初側重於密碼軟體的開發，現在是一個基於Java的持久層框架。一站式 iBATIS提供的持久層框架包括SQL Maps和Data Access Objects（DAO），同時還提供一個利用這個框架開發的JPetStore例項。 相對Hibernate和Apache OJB等“一站式”ORM解決方案而言，ibatis 是一種“半自動化”的ORM實現。縱觀目前主流 所謂“半自動”，可能理解上有點生澀。縱觀目前主流的 ORM，無論 Hibernate 還是Apache OJB，都對資料庫結構提供了較為完整的封裝，提供了從POJO 到資料庫表的全套對映機制。程式設計師往往只需定義好了POJO 到資料庫表的對映關係，即可透過 Hibernate或者OJB 提供的方法完成持久層操作。程式設計師甚至不需要對 SQL 的熟練掌握，Hibernate/OJB 會根據制定的儲存邏輯，自動生成對應的 SQL 並呼叫 JDBC 介面加以執行。新系統的開發 大多數情況下（特別是對新專案，新系統的開發而言），這樣的機制無往不利，大有一統天下的勢頭。但是，在一些特定的環境下，這種一站式的解決方案卻未必靈光。 在筆者的系統諮詢工作過程中，常常遇到以下情況： 1． 系統的部分或全部資料來自現有資料庫，處於安全考慮，只對開發團隊提供幾條Select SQL（或儲存過程）以獲取所需資料，具體的表結構不予公開。 2． 開發規範中要求，所有牽涉到業務邏輯部分的資料庫操作，必須在資料庫層由儲存過程實現（就筆者工作所面向的金融行業而言，工商銀行、中國銀行、交通銀行，都在開發規範中嚴格指定） 3． 系統資料處理量巨大，效能要求極為苛刻，這往往意味著我們必須透過經過高度最佳化的SQL語句（或儲存過程）才能達到系統性能設計指標。 面對這樣的需求，再次舉起 Hibernate 大刀，卻發現刀鋒不再銳利，甚至無法使用，奈何？恍惚之際，只好再摸出JDBC 準備拼死一搏……，說得未免有些淒涼，直接使用 JDBC進行資料庫操作實際上也是不錯的選擇，只是拖沓的資料庫訪問程式碼，乏味的欄位讀取操作令人厭煩。
iBATIS一詞來源於“internet”和“abatis”的組合，是一個由Clinton Begin在2001年發起的開放原始碼專案。最初側重於密碼軟體的開發，現在是一個基於Java的持久層框架。一站式 iBATIS提供的持久層框架包括SQL Maps和Data Access Objects（DAO），同時還提供一個利用這個框架開發的JPetStore例項。 相對Hibernate和Apache OJB等“一站式”ORM解決方案而言，ibatis 是一種“半自動化”的ORM實現。縱觀目前主流 所謂“半自動”，可能理解上有點生澀。縱觀目前主流的 ORM，無論 Hibernate 還是Apache OJB，都對資料庫結構提供了較為完整的封裝，提供了從POJO 到資料庫表的全套對映機制。程式設計師往往只需定義好了POJO 到資料庫表的對映關係，即可透過 Hibernate或者OJB 提供的方法完成持久層操作。程式設計師甚至不需要對 SQL 的熟練掌握，Hibernate/OJB 會根據制定的儲存邏輯，自動生成對應的 SQL 並呼叫 JDBC 介面加以執行。新系統的開發 大多數情況下（特別是對新專案，新系統的開發而言），這樣的機制無往不利，大有一統天下的勢頭。但是，在一些特定的環境下，這種一站式的解決方案卻未必靈光。 在筆者的系統諮詢工作過程中，常常遇到以下情況： 1． 系統的部分或全部資料來自現有資料庫，處於安全考慮，只對開發團隊提供幾條Select SQL（或儲存過程）以獲取所需資料，具體的表結構不予公開。 2． 開發規範中要求，所有牽涉到業務邏輯部分的資料庫操作，必須在資料庫層由儲存過程實現（就筆者工作所面向的金融行業而言，工商銀行、中國銀行、交通銀行，都在開發規範中嚴格指定） 3． 系統資料處理量巨大，效能要求極為苛刻，這往往意味著我們必須透過經過高度最佳化的SQL語句（或儲存過程）才能達到系統性能設計指標。 面對這樣的需求，再次舉起 Hibernate 大刀，卻發現刀鋒不再銳利，甚至無法使用，奈何？恍惚之際，只好再摸出JDBC 準備拼死一搏……，說得未免有些淒涼，直接使用 JDBC進行資料庫操作實際上也是不錯的選擇，只是拖沓的資料庫訪問程式碼，乏味的欄位讀取操作令人厭煩。