相對Hibernate和Apache OJB 等“一站式”ORM解決方案而言，ibatis 是一種“半
自動化”的ORM實現。
大多數情況下（特別是對新項目，新系統的開發而言），這樣的機制無往不利，大有一
統天下的勢頭。但是，在一些特定的環境下，這種一站式的解決方案卻未必靈光。
在筆者的系統諮詢工作過程中，常常遇到以下情況：
1． 系統的部分或全部數據來自現有數據庫，處於安全考慮，只對開發團隊提供幾
條Select SQL（或存儲過程）以獲取所需數據，具體的表結構不予公開。
2． 開發規範中要求，所有牽涉到業務邏輯部分的數據庫操作，必須在數據庫層由
存儲過程實現（就筆者工作所面向的金融行業而言，工商銀行、中國銀行、交
通銀行，都在開發規範中嚴格指定）
3． 系統數據處理量巨大，性能要求極爲苛刻，這往往意味着我們必須通過經過高
度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。
面對這樣的需求，再次舉起Hibernate 大刀，卻發現刀鋒不再銳利，甚至無法使用，
奈何？恍惚之際，只好再摸出JDBC 準備拼死一搏……，說得未免有些淒涼，直接使用JDBC
進行數據庫操作實際上也是不錯的選擇，只是拖沓的數據庫訪問代碼，乏味的字段讀取操作
令人厭煩。
“半自動化”的ibatis，卻剛好解決了這個問題。
這裏的“半自動化”，是相對Hibernate等提供了全面的數據庫封裝機制的“全自動化”
ORM 實現而言，“全自動”ORM 實現了POJO 和數據庫表之間的映射，以及SQL 的自動
生成和執行。而ibatis 的着力點，則在於POJO 與SQL之間的映射關係。也就是說，ibatis
並不會爲程序員在運行期自動生成SQL 執行。具體的SQL 需要程序員編寫，然後通過映
射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。
