相對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，卻剛好解決了這個問題。
這里的“半自動化”，是相對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 的出現顯
得別具意義。