所謂「半自動」,可能理解上有點生澀。縱觀目前主流的 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, 將更有助於發揮ibatis在持久層的優越性:
1. 知道怎樣操做10種以上的數據庫
2. 可配置的caching(包括從屬)
3. 支持DataSource、local transaction management和global transaction
4. 簡單的XML配置文檔
5. 支持Map, Collection, List和簡單類型包裝(如Integer, String)
6. 支持JavaBeans類(get/set 方法)
7. 支持複雜的對象映射(如populating lists, complex object models)
8.對象模型從不完美(不須要修改)
9. 數據模型從不完美(不須要修改)
10. 你已經知道SQL,爲何還要學習其餘東西
3全自動
使用ibatis 提供的ORM機制,對業務邏輯實現人員而言,面對的是純粹的 Java對象,
這一層與經過 Hibernate 實現 ORM 而言基本一致,而對於具體的數據操做,Hibernate
會自動生成SQL 語句,而ibatis 則要求開發者編寫具體的 SQL 語句。相對Hibernate等
「全自動」ORM機制而言,ibatis 以 SQL開發的工做量和數據庫移植性上的讓步,爲系統
設計提供了更大的自由空間。做爲「全自動」ORM實現的一種有益補充,ibatis 的出現顯
得別具意義。
4發展
ibatis本是apache的一個開源項目,2010年這個項目由apache software foundation 遷移到了google code,而且更名爲mybatis。
5開始iBatis之旅