在Java世界Hibernate是最引人關注的一個話題從Gavin King加入EJB EG負責制訂EJB的持久層規范到Gavin King非正式退出JDO EG並且充滿個人情緒的攻擊JDO規范到《Hibernate in Action》的發行再到Hibernate Alpha的發布最後再到最近JBoss PR的發布（使用Hibernate實現Entity Bean）可以說這其中的每一步都引起業界的側目
Hibernate在不到年的時間裡從一個不起眼的開源軟件發展到今天令業界矚目的主流O/R Mapping框架Gavin King從一個開源軟件的作者成為業界舉足輕重的人物這多少有些傳奇的色彩畢竟單純從技術成就而言Hibernate不算是最有成就的Java開源框架軟件到目前為止也不是一個完美無缺的軟件從個人技術水平而言Gavin King也不算絕頂高手
在當前的Java持久層框架中最流行的O/R Mapping產品分別是HibernateJDO和TopLink
自從去年Gavin King加入JBoss之後Hibernate已經由一個民間的開源軟件走上了兼容EJB EntityBean的道路然而更加令人側目的是Gavin King在EJB EG中充當了一個非常重要的角色只要對比一下EJB的EntityBean和Hibernate真相就會大白雖然API接口不同但是 EntityBean的設計理念完全來自於Hibernate
雖然EJB的EntityBean在相當程度上來源於Hibernate但是畢竟是不同的API接口因此Hibernate和EJB EntityBean究竟是怎樣的一種關系是很多人心中的疑問
年四月份JBoss的Ben Wang訪華期間我曾經向Ben請教Hibernate的未來發展他回答說Hibernate未來將仍舊以獨立的軟件產品存在和發展既可以 outside EJB container使用同時Hibernate也將做為JBoss EntityBean Implementation又可以inside EJB container使用然而如何既inside又outside終究缺乏一個感性的認識
月日JBoss發布的 EJB PR揭開了答案從Sourceforge的CVS服務器上面checkout出來源代碼看一下我們可以發現Gavin King對Hibernate進行了簡單的封裝將EJB EntityBean API調用轉換為內部Hibernate自己的API從而實現EJB EntityBean的兼容
EJB 不承諾脫離容器調用如果你想享用EJB則必須運行在某個EJB Vendor提供的容器內例如你使用JBoss提供的容器那麼你調用的是EntityBean API這些調用請求會被轉換為Hibernate API的調用請求這意味著Hibernate實際上提供了兩套API一套是Hibernate原生API另一套是兼容EJB EntityBean API對於那些需要分布式調用支持需要EJB容器的開發人員來說他們選擇後一套API對於不需要EJB容器的開發人員來說他們選擇前一套 API這就是Hibernate既定的發展策略
今年夏天投票通過的JDO標准從某種程度而言並不遜色於 Hibernate當前的版本有些功能甚至比Hibernate還要好例如 JDO支持對類屬性的lazy loading而Hibernate要到才支持當前Hibernate僅僅支持類的lazy loading實際上在去年就已經有很多用戶不斷提出對類屬性的lazy loading的需求然而Gavin King當時一直不認為這個需求有添加的必要性再例如被Gavin King形容為可憎的JDOQL實際上是類SQL查詢語言和對象條件查詢的混合體從功能上來說不如HQL強大但是比Hibernate自己的條件查詢強
不知道究竟出於什麼原因Gavin King對JDO似乎一直懷有由衷的厭惡月他在Hibernate的blog上面對JDO進行了毫不留情的批判列舉了JDO的種種缺點來解釋為什麼EJB持久層規范沒有把JDO考慮進去然而事實上他的批判充滿了對JDO的誤解和偏見例如Gavin King憎恨JDOQL絲毫沒有什麼特別的理由只因為JDOQL不是一個純粹的查詢語言而是一個混合體這多少讓人對Gavin King的風度感到遺憾在被Solarmetric的Abe White反駁之後同樣沒有風度的說我可沒有時間做這種無謂的爭論事實上每個人都認為他自己的技術是最好的……我是錯了JDO那伙人也錯了每個人都會犯錯誤……（所以說人無完人！）
JDO規范的出台事實上構成了對Hibernate乃至基於 Hibernate理念的EJB EntityBean的嚴重威脅JDO規范在功能上的嚴重缺失導致了JDO無力面對Hibernate和TopLink的競爭然而功能基本完備的JDO挾眾多JDO Vendor商業支持的合力同時JDO規范可以避免產品鎖定在某個Vendor的優勢已經將競爭的天平拉直
然而JDO和EJB兩大商業主流標准的分裂是大部分人甚至包括廠商所不希望看到的 於是最終EJB的Lead Linda DeMichiel和JDO的Lead Craig Russell聯名發表公開信宣布了一個合並EJB和JDO持久層規范的計劃新的持久層規范將以JSR（EJB）的持久層規范為基礎融合JDO的部分特性新的持久層規范將進入JEE之中獨立於EJB存在既可以inside JEE容器來使用也可以脫離JEE容器獨立的運行
這個新的持久層框架可以說完全是一個政治的產物EJB Vendors出於自身利益反對JDO使得JDO沒有辦法成為JEE的一部分然而標准的分裂也是大部分人更加不希望看到的於是最終JDO成了政治斗爭的犧牲品從表面上來看JDO和EJB EntityBean都將被新的持久層框架取代似乎JDO並沒有吃虧但實際上JDO標准已經成熟部分JDO領導廠商的產品已經蓄始待發而 EJB EntityBean還處於Early Draft等待產品誕生至少也是一年之後的事情了另外值得耐人尋味的是新的持久層框架將基於當前EJB EntityBean再結合JDO的規范並且將處於EJB EG的控制之下再加入一些JDO EG的成員因此可以看出來新的持久層框架無疑還是以EJB EG為主導進行制定的
從長遠來看EJB和JDO 的政治斗爭對雙方都有好處長期分裂帶來的後果對雙方的發展都不利然而從短期來看JDO確實是在這場政治斗爭中敗下陣來最直接的體現就是已經有一些JDO的用戶對JDO的前景產生了動搖和迷茫不少的JDO愛好者更是直言JDO將死
TopLink是一個老牌的 O/R Mapping軟件了自從被Oracle收購之後又增加了對Oracle數據庫的良好支持和對Oracle AS EntityBean的支持Oracle提供了TopLink的圖形設計環境可以使得設計好的TopLink域模型既可以被單獨用在TopLink 中也可以被用在EJB CMP中因此看來TopLink也走了一條和Hibernate同樣策略的路
TopLink的問題在於相比Hibernate的開源和免費的優勢來說TopLink既不開源售價又不菲上本來商業軟件TopLink應該在技術支持和商業宣傳策略上擁有足夠的優勢然而Oracle公司畢竟是一個以數據庫為核心產品的公司其他的一切產品都是為了數據庫銷售業績而服務的在Oracle產品線中處於一個從屬地位的TopLink由於先天不足只能眼睜睜看著Hibernate的日益壯大而無所作為因此 TopLink更多的被局限在購買了Oracle數據庫並且綁定Oracle數據庫的用戶群體中
JEE的新持久層規范將毫無懸念的成為未來持久層框架的主流API無論是HibernateJDO還是TopLink終將兼容這個主流商業API在當前的這三種持久層API當中Hibernate無疑是最有前途的這是因為新的持久層規范將基於EJB EntityBean規范這意味著仍將以Hibernate的設計理念為基礎
JBoss對EJB規范跟隨的步伐非常緊密在規范制定過程中就不斷的發布參考實現產品因此可以對對EJB規范產生比較大的影響力
綜上所述我們有理由對Hibernate的前途抱有強烈的信心
最後的一個疑問是既然JEE的新持久層框架可以脫離JEE容器運行那麼大家不全部都去用Hibernate的後一套兼容API而完全放棄Hibernate的原生API了嗎？那麼是否意味著Hibernate做為一個獨立產品的使命徹底終結呢？
對於這個問題我的看法是JEE的持久層規范要綜合各個EJB VendorJDO Vendor的意見要平衡他們之間的利益得失那麼這樣一個瞻前顧後的規范必然無法覆蓋所有應用場合的全面需要這不像Hibernate的原生API 可以隨時根據開發人員的要求增加功能那麼靈活因此我預計Hibernate的原生API以其更加強大的功能仍然會吸引一大批人直接使用原生API而不是兼容JEE規范的API
總而言之對於我們當前的持久層開發來說最好的辦法莫過於堅定的使用DAO層來隔離持久層和業務層邏輯那麼不管未來持久層風雲如何變換但凡基於POJO的持久層框架都可以被我們拿來任意替換
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28932.html
