之前開發中曾用到ibatis,一直想找個時間總結一下,但是一直都沒有時間啊.
看了robbin大哥之前的老帖,ibatis最終還是加入apache(http://ibatis.apache.org/index.html)項目了,我想這也算是它的最終歸宿吧,至少它的命運相比mysql算是幸運的了.呵呵.當然對於我們這些現在晚輩來講,也許現在學習它已經過於晚了一些了.但畢竟聞道有先後嘛.
現在開始進入正題(也許下面講的一些都是廢話,但對於初學者去理解ibatis,我個人覺得是很有用的):
相對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 的出現顯
得別具意義。