Hibernate FAQ

- 中國WEB開發者網絡 (http://www.webasp.net)
-- 技術教程 (http://www.webasp.net/article/)
--- Hibernate FAQ (http://www.webasp.net/article/23/22129.htm)
-- 作者:未知
-- 發佈日期: 2005-04-30
下面的文章只是讓大家認識一下Hibernate的優勢和未來,有沒有必要學習要看你的實際需求,不過還是建議你在有時間的情況下研究一下,如果能用到項目當中那更好。如果你的基礎還沒有牢固,請你三思而行。 Hibernate FAQ 初學者必讀! 1、Hibernate是什麼? Hibernate是一個優秀的開發源代碼的Java對像持久層輕量級封裝框架,它既可以用來在Java應用程序中取代大部分JDBC代碼,也可以整合到J2EE系統中作為持久層框架。 2、Hibernate的官方網站是什麼? http://www.hibernate.org/ 3、Hibernate是誰開發的? Gavin King 4、Hibernate的下載地址? http://sourceforge.net/projects/hibernate/ 5、Hibernate的文檔在哪裡? http://www.hibernate.org/5.html 6、Hibernate的當前穩定版本是哪個版本 Hibernate2.0.3 7、Hibernate有專門的論壇嗎? 官方論壇(英文) http://forum.hibernate.org/ 國內論壇(中文) http://forum.hibernate.org.cn/ 8、Hibernate有例程嗎? http://www.hibernate.org/30.html ----------------------------------------------------------- Hibernate入門容易,掌握精通我也不敢自誇。我第一遍看Hibernate文檔的時候也覺得很吃力,但不是因為Hibernate難掌握而感到吃力,是因為Hibernate文檔處處都是持久層設計的經驗和最佳實踐。Hibernate文檔準確的來說,絕大部分內容都在講對象的持久層設計,而不是簡單的Hibernate使用,使用問題查Java doc就夠了。所以學習Hibernate,主要是在學習持久層的設計模式,如果你把Hibernate文檔都看完了,還整天只會提那些 Hibernate的配置問題,Hibernate的類調用問題,我覺得這樣的人還沒有真正的入門,算是白學了。 我對Hibernate 的那些配置也不是特別純熟,每次寫hbm,都要對照文檔一點點的檢查;類調用參數也不太記得,寫代碼也要Java doc隨時備查。但是我在學習Hibernate的時候即集中所有精力來理解Hibernate的運行原理,集中精力來掌握持久層設計應該把握的原則和技巧,這些才對我是最重用的東西。毫不誇張的說,學習完Hibernate,我對JDBC的編程也提高了一大截,更不要說對於J2EE架構的持久層的框架設計,基本上是瞭然於胸了,即使將來換了API,不用Hibernate的,改用JDO,Castor什麼的,這些經驗一樣照用。 學習Hibernate主要不是在學習Hibernat怎麼配置,用工具怎麼生成hbm文件,如果你把重點放在這裡,基本上等於白學了Hibernate。Hibernate的精華在於無與倫比的靈巧的對象持久層設計,這些持久層設計經驗不會因為你不用Hibernate而喪失掉,我自己學習Hibernate,已經明顯感覺到對持久層設計能力已經長了很多經驗值了,這些經驗甚至不光可以用在Java上,用在.net上也是一樣。所以Hibernate配置的學習,我只是簡單看看,用的時候知道到那裡去查就行了,一堆複雜的生成工具我根本就看都不去看,這樣算下來,掌握Hibernate的配置,可以用Hibernate來替代JDBC寫程序,不過花上3天時間就足夠了。我想3天時間對你來說不算很奢侈的學習代價吧。 為什麼我這麼強調學習Hibernate的對象持久層設計理念呢?那就看你的理想是想一輩子做一個程序員呢?還是想向更高的方向發展呢?從純做技術的角度來說,職業發展的最高點是“系統架構師”,Bill Gates不是還叫做微軟的首席系統架構師嗎?System Architect職位需要的是你的學習和領悟能力,如果你不能把學習Hibernate得到的設計經驗運用到其它地方,那麼你是失敗的,也沒有資格做 System Architect。 不管JDO也好,Hibernate也好,TopLink也好,CocoBase也好,還是 Castor,還是什麼Torque,OJB,軟件的使用和配置方法可以各異,但本質上都是ORM,都是對JDBC的對象持久層封裝,所以萬變不離其宗,如果你完整的學習和掌握Hibernate花了1個月的時間,那麼你再學習OJB的時間不應該超過1個星期,因為你已經把對像持久層設計都瞭然於胸了,你需要的只是熟悉一下OJB的API和配置罷了,至於怎麼運用OJB進行持久層的開發你早就已經熟悉了。 所以當你掌握了兩種以上的ORM,你應該能夠不拘於使用的ORM軟件的限制,設計出適合於你的項目的持久層來,這才是System Architect的水準。用金庸小說來打個比方來說吧,張無忌學太極劍,只記劍意,不記劍招,這才是真正的高手,而低手就只會去學習劍招,而不去領會劍招背後蘊含的劍意,所以一輩子都是低手,永遠不能真正學會太極劍。所以周顛看到張三豐第二次演示太極劍,招式完全不同就以為是另一套東西,其實本質上都一樣。學習Hibernate也不要捨本逐末的去學各種五花八門的工具,重點掌握它的對象持久層設計理念。 -------------------------------------------------------------- 我來談談我為什麼學習Hibernate,希望對大家能有點啟發。 在我做過的很多項目的過程中,我一直有一個懸而未決的問題在困擾我,那就是持久層的開發。持久層的開發一般來說要麼用CMP,要麼用JDBC+DAO。 CMP就不用說了,它對我來說是一種失敗的實踐,而JDBC+DAO也存在很多的困難,我很難做到把關係表記錄完整的映射到持久對象的關係上來,這主要體現在多表的關係無法直接映射到對持久對象的映射上來,可能是一個表映射多個持久對象,有可能是多個表映射一個持久對象,更有可能的是表的某些字段映射到一個持久對象,但是另外一些字段映射到別的持久對像上。而且即使這些問題都處理好了,也不能直接按照對象的方式來對持久對像(PO)編程,因為存在1:N關係的持久對象的查詢其實就是1+n次對數據庫的SQL,我曾經有一次失敗的持久層設計,結果是某個關聯很多其它持久對象的PO一查詢就是5n+1次 sql,速度慢的不得了,最後不得不整個修改底層設計,最後等於是完全拋棄了對象設計,完全是按照表字段進行操作。 但是這樣做非常難受,因為系統的設計是從需求設計,系統設計這樣自頂而下的,結果都到了詳細設計階段了,被持久層映射問題限制,不得不自底向上修改設計方案,又回到了按照過程進行編程的老路上來,非常的糟糕。 我對這個問題思考了很久,最後終於意識到這其實是一個很經典的問題:對像和關係的映射問題。實際上自從OOP編程流行以後,就存在這個難題了,所以才有人提出關係數據庫進行重新設計,改用對像數據庫,但實際上關係數據庫並沒有被淘汰,於是就只能在上層的應用層找解決方案。這時候我明白了我需要的實際上是一種 ORM產品。 我最早想到的ORM就是JDO,於是我下載了兩個JDO產品,準備認真的學習一下,但是研究了一段時間之後,我發現我對JDO非常的失望,原因如下: 1、 JDO沒有一個好的開源免費實現,好的產品都是商業產品,並且在國內沒有銷售和技術支持。這就造成了JDO只有學習之用,不能把它用在實際項目中,否則的話,你把軟件賣給客戶的時候,還要告訴他,你還要另外去買一個國外的軟件產品,並且在國內沒有技術支持,出了持久層的問題,我們也解決不了,請你自己打國際長途去解決問題,你認為客戶能答應嗎? 2、JDO不是一個輕量級封裝,它試圖建立一個完整的持久層框架,但是還很不完善,造成了JDO 感覺比較笨重,很多操作方式令人覺得煩瑣和古怪。這加重了程序員學習和編程的負擔,而且封裝的太多會造成一個嚴重的問題就是一旦出現報錯信息,調試起來非常困難,你很難準確的定位錯誤究竟出在哪裡,封裝的越輕,問題越容易定位,越容易解決,封裝的越重,問題越複雜,越找不到原因,CMP就是一個很好的例子,出了錯誤,調試起來非常困難和麻煩。 3、JDO的標準很不完善,存在重大缺陷。最主要的問題體現在PO不能脫離PM(相當於 Hibernate的Session)而存在,這是個非常嚴重的問題,會造成編程的時候進行大量VO的拷貝操作,煩瑣極了;另外一個重大缺陷是靜態的 POJO的Enhancer,不能運行期動態Enhance,無法進行增量編譯和調試,編程和調試起來非常煩瑣,每次都要手共運行一個工具對POJO進行 Enhance;此外還有一些缺陷,例如JDOQL不完善,映射關係的表達不夠強大等等。 4、JDO產品的分裂。這個問題也比較嚴重,由於JDO1.0標準的缺陷,而JDO2.0標準還遙遙無期,而各個JDO廠商為了能夠在競爭中脫穎而出,那麼除了在易操作性和性能上的提高之外,想要吸引客戶,就必須有自己的產品特色。那麼1.0標準的缺陷正好給了他們發揮的舞台,每個廠商都會有自己獨到的解決方案來解決標準的缺陷,然而這卻造成了JDO 產品事實上的分裂。這種分裂嚴重到什麼程度?我可以簡單舉個例子:你寫好的POJO,用一種JDO的Enhancer進行Enhance過以後得到的 PO,在另一個JDO產品上跑不起來。這很像當年Unix的分裂,結果就是二進制代碼級的不兼容,而只能在C源代碼級兼容。現在的JDO也有這樣的趨勢,就像App Server的差別一樣,一個在Weblogic上開發好的EJB,移植到Websphere,你一定需要重新進行配置。 我心目中的ORM最好有如下的特點: 1、開源和免費的License,我可以在需要的時候研究源代碼,改寫源代碼,進行功能的定制。 2、輕量級封裝,避免引入過多複雜的問題,調試容易,也減輕程序員的負擔。 3、具有可擴展性,API開放,當本身功能不夠用的時候,可以自己遍碼進行擴展。 4、開發者活躍,產品有穩定的發展保障。 拋棄了JDO以後,我根據上面的原則,先後排除了TopLink,CocoBase,Castor等,最後選擇了Apache OJB和Hibernate。 OJB的排除很容易做出,一是因為它的文檔太簡單,太少;二是因為OJB計劃下一個版本全面支持JDO,它的API會有重大變動,所以現階段學習OJB是個錯誤,等它的API穩定了以後再學習不遲。 Hibernate的發現是很偶然的事情,只是在別人提到JDO的產品中,附帶提了提而已,但當我開始研究Hibernate之後,我發現終於找到了我夢寐以求的ORM了。 Hibernate 完全符合我上面提到的標準之外,也解決掉了JDO的所有缺陷,而且方式之優雅令人讚歎。Hibernate的文檔也是非常非常有特色的地方,它不僅僅是 Hibernate的功能介紹那麼簡單,它實際上是一個持久層設計的最佳實踐的經驗總結,文檔裡面的例子,文檔裡面的總結全部都是最佳設計的結晶。我認真的把Hibernate讀下來的感覺就是,不單單把Hibernate掌握住了,而且對持久層的設計的經驗都長了一大塊,以前可從來沒有覺得持久層的設計還有那麼多的學問,也由此感覺到Gavin絕對是一個大牛人。 當然選擇Hibernate最最重用的原因是Hibernate是一個我能夠完完全全駕馭的了的軟件。Hibernate的源代碼非常少,而且寫的非常簡潔,我總覺得挺奇怪的,這麼少的源代碼能夠實現這麼多的功能,是個奇跡。 Hibernate的源代碼樹分的很清楚簡單,源代碼很易讀,我一旦碰到文檔中沒有講到的問題,或者文檔中提到但是我搞不清楚的地方,我就去源代碼中找,所有的問題都豁然開朗,而且讓我對Hibernate的運行原理和細節搞的特別清楚,好像Hibernate就像自己寫的代碼一樣,很清楚的知道,怎麼寫程序可以讓Hibernate運行效率最高,最省內存,程序出了錯誤,很清楚的知道是什麼地方的問題,怎麼解決。所以用Hibernate讓我特別放心,我能夠駕馭它,而不像那些過於複雜的軟件,本身框架就複雜的很,再加上不開源,出了問題也不知道怎麼回事。 ------------------------------------------------------------ 一、Hibernate是JDBC 的輕量級的對象封裝,它是一個獨立的對象持久層框架,和App Server,和EJB沒有什麼必然的聯繫。Hibernate可以用在任何JDBC可以使用的場合,例如Java應用程序的數據庫訪問代碼,DAO接口的實現類,甚至可以是BMP裡面的訪問數據庫的代碼。從這個意義上來說,Hibernate和EB不是一個範疇的東西,也不存在非此即彼的關係。 二、Hibernate是一個和JDBC密切關聯的框架,所以Hibernate的兼容性和JDBC驅動,和數據庫都有一定的關係,但是和使用它的Java程序,和App Server沒有任何關係,也不存在兼容性問題。 三、 Hibernate不能用來直接和Entity Bean做對比,只有放在整個J2EE項目的框架中才能比較。並且即使是放在軟件整體框架中來看,Hibernate也是做為JDBC的替代者出現的,而不是Entity Bean的替代者出現的,讓我再列一次我已經列n次的框架結構: 傳統的架構: 1) Session Bean <-> Entity Bean <-> DB 為了解決性能障礙的替代架構: 2) Session Bean <-> DAO <-> JDBC <-> DB 使用Hibernate來提高上面架構的開發效率的架構: 3) Session Bean <-> DAO <-> Hibernate <-> DB 就上面3個架構來分析: 1、內存消耗:採用JDBC的架構2無疑是最省內存的,Hibernate的架構3次之,EB的架構1最差。 2、運行效率:如果JDBC的代碼寫的非常優化,那麼JDBC架構運行效率最高,但是實際項目中,這一點幾乎做不到,這需要程序員非常精通JDBC,運用 Batch語句,調整PreapredStatement的Batch Size和Fetch Size等參數,以及在必要的情況下採用結果集cache等等。而一般情況下程序員是做不到這一點的。因此Hibernate架構表現出最快的運行效率。 EB的架構效率會差的很遠。 3、開發效率:在有JBuilder的支持下以及簡單的項目,EB架構開發效率最高,JDBC次之,Hibernate最差。但是在大的項目,特別是持久層關係映射很複雜的情況下,Hibernate效率高的驚人,JDBC次之,而EB架構很可能會失敗。 4、分佈式,安全檢查,集群,負載均衡的支持 由於有SB做為Facade,3個架構沒有區別。

webasp.net