相對Hibernate和Apache OJB 等“一站式”O(jiān)RM解決方案而言，ibatis 是一種“半
自動化”的ORM實現(xiàn)。
所謂“半自動”，可能理解上有點生澀。縱觀目前主流的ORM，無論Hibernate 還是
Apache OJB，都對數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，提供了從POJO 到數(shù)據(jù)庫表的全
套映射機制。程序員往往只需定義好了POJO 到數(shù)據(jù)庫表的映射關(guān)系，即可通過Hibernate
或者OJB 提供的方法完成持久層操作。程序員甚至不需要對SQL 的熟練掌握，
Hibernate/OJB 會根據(jù)制定的存儲邏輯，自動生成對應的SQL 并調(diào)用JDBC 接口加以執(zhí)
行。
大多數(shù)情況下（特別是對新項目，新系統(tǒng)的開發(fā)而言），這樣的機制無往不利，大有一
統(tǒng)天下的勢頭。但是，在一些特定的環(huán)境下，這種一站式的解決方案卻未必靈光。
在筆者的系統(tǒng)咨詢工作過程中，常常遇到以下情況：
1． 系統(tǒng)的部分或全部數(shù)據(jù)來自現(xiàn)有數(shù)據(jù)庫，處于安全考慮，只對開發(fā)團隊提供幾
條Select SQL（或存儲過程）以獲取所需數(shù)據(jù)，具體的表結(jié)構(gòu)不予公開。
2． 開發(fā)規(guī)范中要求，所有牽涉到業(yè)務邏輯部分的數(shù)據(jù)庫操作，必須在數(shù)據(jù)庫層由
存儲過程實現(xiàn)（就筆者工作所面向的金融行業(yè)而言，工商銀行、中國銀行、交
通銀行，都在開發(fā)規(guī)范中嚴格指定）
3． 系統(tǒng)數(shù)據(jù)處理量巨大，性能要求極為苛刻，這往往意味著我們必須通過經(jīng)過高
度優(yōu)化的SQL語句（或存儲過程）才能達到系統(tǒng)性能設計指標。
面對這樣的需求，再次舉起Hibernate 大刀，卻發(fā)現(xiàn)刀鋒不再銳利，甚至無法使用，
奈何？恍惚之際，只好再摸出JDBC 準備拼死一搏……，說得未免有些凄涼，直接使用JDBC
進行數(shù)據(jù)庫操作實際上也是不錯的選擇，只是拖沓的數(shù)據(jù)庫訪問代碼，乏味的字段讀取操作
令人厭煩。
“半自動化”的ibatis，卻剛好解決了這個問題。
這里的“半自動化”，是相對Hibernate等提供了全面的數(shù)據(jù)庫封裝機制的“全自動化”
ORM 實現(xiàn)而言，“全自動”O(jiān)RM 實現(xiàn)了POJO 和數(shù)據(jù)庫表之間的映射，以及SQL 的自動
生成和執(zhí)行。而ibatis 的著力點，則在于POJO 與SQL之間的映射關(guān)系。也就是說，ibatis
并不會為程序員在運行期自動生成SQL 執(zhí)行。具體的SQL 需要程序員編寫，然后通過映
射配置文件，將SQL所需的參數(shù)，以及返回的結(jié)果字段映射到指定POJO。
使用ibatis 提供的ORM機制，對業(yè)務邏輯實現(xiàn)人員而言，面對的是純粹的Java對象，
這一層與通過Hibernate 實現(xiàn)ORM 而言基本一致，而對于具體的數(shù)據(jù)操作，Hibernate
會自動生成SQL 語句，而ibatis 則要求開發(fā)者編寫具體的SQL 語句。相對Hibernate等
“全自動”O(jiān)RM機制而言，ibatis 以SQL開發(fā)的工作量和數(shù)據(jù)庫移植性上的讓步，為系統(tǒng)
設計提供了更大的自由空間。作為“全自動”O(jiān)RM實現(xiàn)的一種有益補充，ibatis 的出現(xiàn)顯
得別具意義。