robbin:我為什麼要學習Hibernate?

來源:互聯網
上載者:User

作者:robbin

在我做過的很多項目的過程中,我一直有一個懸而未決的問題在困擾我,那就是持久層的開發。持久層的開發一般來說要麼用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讓我特別放心,


相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。