對ibatis不錯的分析

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