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