http://dev2dev.bea.com.cn/techdoc/webplat/2004122804.htm窗外,一些 BMX (自行車越野賽)車手們正努力訓練一種新特技。他們不能再把賽車摔壞了,因為在他們的練習斜坡旁邊損壞的賽車已經堆了三個星期了。那堆生銹扭曲的金屬讓我聯想到 Java 持久性的前景。
Java 開發社區正在為持久性的問題傷腦筋,而且已經持續很長的一段時間了。只要您仔細觀察,就會發現我們自己的那堆扭曲的金屬:
- 面向對象數據庫的供應商都奄奄一息。
- EJB 1.0 持久性很是嚇人。
- Oracle 收購了 TopLink,震動了關系映射市場。
- 制定 JDO 規范和取得一些發展整整花費了很長的一段時間。
盡管如此,我們還是有理由保持樂觀。小型廠商和開放源代碼社區正在合作為 EJB 持久性模型尋找合適的替代品。
什么是持久性?
在深入討論之前,我們應當給持久性下個定義。在其最廣泛的形式中,持久性涉及到獲取臨時數據(比如內存里的程序數據)并存儲為更持久的形式。本文中我們將使用一種更加通用的定義:
持久性框架將以最原始形式存在的臨時程序數據轉換成持久的數據存儲,或執行相反的操作。
在我們的示例中,持久的數據存儲很可能是關系數據庫,而其原始形式是內存中的對象組成的 Java 程序。持久性框架負責管理數據庫和在數據庫與對象之間建立映射。
圍繞持久性問題發生了很多激烈的爭論,這并不會使我們驚奇。持久性本身就是一個棘手的問題。持久性框架應當允許關系數據庫和對象之間靈活的建立映射,使模型之間產生沖突。持久性框架還必須提供惟一標識,而不會產生瓶頸效應。本文主要討論這兩個在 Java 中差別最大的問題。
持久性框架在其他方面也會有差異,但是他們似乎是 Java 的主要戰場。這些是通用的持久性框架,他們各有優缺點。持久性框架都在為實現透明性而努力,并盡可能的模仿 Java語言。它們還必須引入諸如 lazy loading 和 aggressive caching 等性能特性來彌補抽象化關系數據庫存取所帶來的固定管理費用。
四種框架
本文將重點介紹四種不同的框架。每一種都在市場上占有一席之地。每一種也都有各自的缺點。我們將盡量介紹他們的優缺點。
可行的 EJB CMP
如果您正在用 EJB,那么就假設您只有一種選擇:具有容器管理持久性(CMP)的 EJB 實體。由于 CMP 與 J2EE 應用程序服務器一起出售,因而它比市場上的其他產品更有優勢。IBM、Sun 和 BEA 為制定了強大的政策支持。CMP 具備其作為市場領導者和作為 J2EE 標準組成部分的所有優勢。
在很多客戶通過 CMP 實現了成功地解決方案的同時,EJB 持久性很早就備受爭議。在 EJB 2.0 之前,規范托管遠程界面,而且不能表現對象之間的關系。這兩個問題嚴重影響了性能,但是在 EJB 2.0 中都得到了解決?,F在,一些 J2EE 客戶可以高效的使用 EJB CMP,借助了合理的的性能。盡管如此,問題依舊存在。一些研究人員和客戶正確地指出,EJB 持久性模型過于復雜并且存在基礎缺陷:
- 組件導向。EJB 實體模型是一種組件模型,具有開發復雜度。也就是說,您無法表達繼承這樣的概念。您還必須為創建大部分實體編寫六個 class(雖然一些開發環境和諸如 Xdoclets 的工具可以幫助您完成部分工作)。
- 粗糙。EJB 容器適合解決粗粒度(coarse-grained)問題,比如大段代碼的安全性問題。而對解決細粒度(fine-grained)問題則不是很有效,比如小段代碼的持久性問題。(BEA 的應用程序服務器可以通過優化減輕問題,允許您關閉部分容器服務。)
- 靜態。EJB 查詢必須在部署時就綁定,所以您無法建立動態查詢。
總之,EJB 實體 bean 不能解決所有的問題,諸如復雜對象模型的持久性問題。但是,我們還擁有一些優秀解決方案。
專有的關系對象(OR)映射程序
兩到三年之前,本文不會是一篇讓人很感興趣的文章。如果您想使用一種非常正式的 Java 持久性框架,那么就會選擇 TopLink,它是以前市場的主宰。TopLink 速度快,并且可以快速的建立復雜關系映射,并且提供類似EJB 的幾乎透明的 Java 模型。不過 Oracle 最近收購了 TopLink,而且 Oracle既是數據庫供應商又是應用程序服務器供應商。如果您是一個 WebLogic 用戶或者使用非 Oracle 的數據庫,您就會在買 TopLink 之前仔細考慮一下。對于 Oracle 的用戶來說這是個很好的產品,但是對于其他人來說就必須考慮 TopLink 潛在的方向性改變。當然了,您也可以購買其他的專有的 OR 映射程序。隨之帶來的問題是您購買了一種具有較低市場占有率的專有產品。您就不得不為此付出更多的資金來培訓員工、聘請經驗豐富的開發人員和購買配套工具。盡管用戶會尋找專有的關系映射程序之外的產品,TopLink 還是市場的主宰。
JDO 是一個開放的替代產品
1998年,推廣 JDO 的 Java Specification Request (JSR)被提交到 Java Community Process (JCP)。這是第12個 JSR,完成于2002年8月份。JDO 是一種透明持久性的規范。它沒有規定數據存儲的類型:為面向關系數據庫和面向對象數據庫都提供了解決方案。
JDO 的優點之一是它能很好的與大部分應用程序服務器結合使用。例如,SolarMetric 的 KodoJDO就是一個主流的 JDO 實現。您可以將其與 WebLogic 相結合,您的聲明事務可以通過容器工作,正如您使用 CMP 一樣。JDO 還有一些強大的功能:
- JDO 是一種標準界面。它由 JCP 正式制訂,因此它比其他大部分的專有解決方案更權威。
- JDO 是透明的。您可以更自由地持久性 Java 對象模型。用 JDO 可以更容易地持久性抽象 class 和繼承關系。
- JDO 具有靈活性。您可以持久性到多個數據源。您可以從多種商業實現中選擇,或者使用開放源代碼替代產品。(OJB 就很不錯。)
盡管 JDO 是一個快速靈活的標準持久性框架,它仍然有反對者。有些人不喜歡大部分的 JDO 實現通過字節碼增強來實現透明性。在使用 JDO 時,Java 源文件被編譯成 class 文件。當需要持久性 class 時,為了產生可持久性的 class,必須通過字節碼增強程序來運行這個 class。一些架構師認為字節碼增強程序使構造過程復雜化,使調試更困難。然而,我至今還沒有找到一位經歷過這些問題的開發人員。需要注意的是,Java 字節碼是基于開放規范的,正如 sJava 語言一樣。
JDO 的另一個缺點是它沒有市場沖擊力?;蛟S真是如此,但是 SolarMetric 最近將兩項強大的技術廉價地整合到它的 JDO 產品中。注意,JDO 規范的1.0版本發布只有一年。那還只是很短的時間,現在下結論還為時過早。
最后,JDO 標準并沒有規定對象到關系的映射。這就意味著您的映射文件在各種實現之間并不是可移植的。專有解決方案也存在這個問題。
Hibernate 是一個開源的寵兒
如果您正在尋求一個優秀的持久性框架,并且您喜歡開源軟件的話,試試 Hibernate。它是個輕量級的持久性框架,功能卻非常豐富。和 JDO 一樣,用 EJB 或者不用 EJB,它都能與 Weblogic 結合得很好。其基本優勢如下:
- Hibernate 使用 Java 反射機制 而不是字節碼增強程序來實現透明性。
- Hibernate 的性能非常好,因為它是個輕量級框架。
- 映射的靈活性很出色。它支持各種關系數據庫,從一對一到多對多的各種復雜關系。
Hibernate 也有一些缺點。它限制您所使用的對象模型。(例如,一個持久性類不能映射到多個表)其獨有的界面和可憐的市場份額也讓人不安,盡管如此,Hibernate 還是以其強大的發展動力減輕了這些風險。其他的開源持久性框架也有一些,不過都沒有 Hibernate 這樣有市場沖擊力。
沒有明確的選擇
當然,您可以自己寫一個持久性框架,甚至壓根就不用。您也可能會將注意力集中在另一個興起的市場:數據聯合(data federation),不過那是另一篇文章需要討論的。
只要市場領頭羊出現一些實際的或是被察覺到的問題,混亂的情況就會隨之而來。Java 持久性也不例外。CMP是市場的領導者,但是 EJB 這一后盾正在開始走向某種輪回的死亡階段。而作為替代品,TopLink 面臨消退,Hibernate 則迅速上升。擁有許多優秀供應商的 JDO 是個好的選擇,它也開始有所作為。
從窗戶還能看到那堆生銹的自行車,不過那幫年輕人已經完成了一些特技。Java 行業也剛剛開始解決持久性的問題。
參考資料
- 此文很好地描述了持久性框架的根本問題。
- 您可以在這里獲得關于 JDO 更深入的了解。
關于作者
Bruce 是位于德克薩斯州奧斯汀的 J2Life,LLC 公司的獨立顧問。他擁有15年軟件開發經驗,并且是4本書的作者,包括暢銷書《Bitter Java》和最近出版的《Bitter EJB》。他擅長技術技術寫作和設計審計,特別是數據。
原文出處 http://dev2dev.bea.com/products/wlplatform81/articles/Java_Persistence.jsp