JDO

原文:http://www.libelis.com/inner-index.jsp?next=jdo.html

JDO是Java對象持久化的新的規範。JDO經SunJava Community Process認定。

一、歷史

JDO是對象持久化工作的綜合成果,試圖提供一個對象持久化的完全版本。JDO同時繼承於ODMG(對象數據管理小組,標準化對象數據庫的一個獨立委員會)和對象關係映射工具提供商。
JSR #000012 approved in July 1999
1999-8組建的專家小組:包括Sun、Apple、BEA、IBM、Oracle、SAP、WebGain等
2000-5 完成公開評論草案
2000-6 在JavaOne上引入
2001-3 最終草案0.93
2001-5 最終草案0.96公佈
2001-6 在JavaOne上啓動
2001-11 最終草案0.98

二、目標

定義對象級的持久化。
  • 完全支持對象模型,包括引用、集合、接口、繼承
  • 完全透明持久化:這使得業務對象完全獨立於任何數據庫技術,這使用了一個字節碼增強機制(a byte-code enhancement mechanism)。
  • 縮短開發週期(不再需要映射)
  • 在開發小組中清晰地劃分業務人員和數據庫人員。
  • 通用持久性
        JDBC限於RDBMS,JDO潛在地可以處理任何類型的數據源,包括RDBMS,ODBMS,TP監控處理,ASCII無格式文件,xml文件,properties文件,大機上的Cobol數據庫,等
        JDO是面向大型信息系統的一個完全的解決方案,在這樣的系統中,信息存儲於多種異質數據源
  • 涵蓋J2EE、J2SE、J2ME的廣泛實現
  • 強壯的事務模型
  • 同時支持C/S和多層體系結構


三、體系

JDO 包
PersistentCapable:擁有持久實例的類必須實現這個接口。管理對象生命週期。
PersistenceManager :代表了到數據源的連接。一個應用可以打開一個或多個PersistenceManagers。
PersistenceManagerFactory:允許從數據源中得到一個PersistenceManager的實例,這個工廠也可以作爲一個連接池。 
Transaction:允許界定事務 
Query :允許明確地聲明性地使用JDO查詢語言從數據源中獲取數據。NB:也可以通過引用之間的基本的定位,隱含地、透明地從數據源中獲取對象。 
InstanceCallback:在數據庫操作中(比如before/after read, before/after write,等),定義一些鉤子,以做特殊處理(像暫時屬性的初始化)。
JDOException:JDO操作中拋出的例外。

JDO也定義了幫助類,對象標識(由應用或數據源管理)
JDO實現可以支持或不支持兼容的PersistenceManager(當PersistenceManager是兼容的時,你可以得到存儲於不同數據庫的對象引用)。
NB:在JDO的第一個發佈版本中,並沒有嚴格地定義鎖和鎖策略。

JDO對象模型
  • JDO對象模型基本上是Java的對象模型,包括所有的基本類型,引用,集合和事件接口。
  • 除了系統定義類(system-defined classes),支持所有的字段類型(包括簡單型、可變和不變的對象類型〔immutable and mutable object types〕、用戶定義類、數組、集合、接口)。
  • 支持所有的成員變量修飾符(private, public, protected, static, transient, abstract, final, synchronized, volatile)
  • 除了對象狀態依賴於不可訪問的或遠程對象,即繼承於java.net.SocketImpl、本地方法等,所有的用戶定義類都可以是PersistentCapable。


JDO對象生命週期
爲了能夠在數據源中訪問、存儲對象,應用必須首先得到一個或幾個數據源的連接。一個JDO PersistenceManager對象就代表了這樣一個連接。它可以通過PersistenceManagerFactory類得到。持久化對象必須是實現了PersistentCapable接口的類的實例。這樣的類可能同時擁有持久化的或臨時的(transient)實例。

爲了使一個實例持久化,編程者必須調用PersistentManager的makePersistent方法。通知JDO對象爲持久化或臨時的很重要,即使它們可以從JDO的行爲中得到它是臨時的,比如事務管理和對象標識。對象標識可以由應用管理,或者由數據源代理(這大多是在使用ODBMS實例時,因爲概念ObjectID本身就是ODMG模型的一部分)。

JDO支持一種持久化模型,這這種模型中持久性自動傳播到引用的對象。這種機制經常稱爲“延伸持久(persistence by reachability)”或者“傳遞持久(transitive persistence)”。這意味着一旦一個已經持久化的對象引用了一個臨時對象,這個臨時對象自動變成持久化的。對於JDBC編程者,這個模型可能很奇怪,但是他們會發現這是大多數情況下編程者希望從持久化框架中得到的支持。

例子:
  1. pmf = (PersistenceManagerFactory) (Class.forName("com.libelis.lido.PersistenceManagerFactory").newInstance()); 
  2. pmf.setConnectionDriverName("versant"); 
  3. pmf.setConnectionURL(dbName); 
  4. pm = pmf.getPersistenceManager(); 
  5. tx = pm.currentTransaction(); 
  6. tx.begin(); 
  7. Provider aProvider = new Provider("LIBeLIS"); 
  8. pm.makerPersistent(aProvider); // aProvider now persists 
  9. Address anAddress = new Address("25 rue Paul Barruel""France""Paris"); 
  10. aProvider.address = anAddress ; // anAddress now persists 
  11. tx.commit(); 
  12. pm.close(); 

對象或者通過明確的JDO查詢結果從內存中得到,或者通過標準的Java對象之間的導航(navigation)得到。

最後這個機制很強大,你可以把持久對象想像爲在JVM堆中的一個特殊的部分,我們稱之爲“客戶端緩存(client cache)”。每次當你企圖從一個對象導航到另一個時,如果這個對象尚不在內存中,JDO會自動從數據源中獲取,並把它放在緩存中。

例子
假設aProvider對象已經裝載到內存,但是它的Address對象還沒有。當你寫下如下代碼時:
  1. System.out.println(aProvider.address.city);

Address對象會自動裝載。緩存管理自動鏈接到事務邊界(transaction boundaries),這意味着緩存將在事務結束是刷新,所有的實體都標示爲無效的。下次對象訪問它們的狀態時,自動地、透明地從數據源中再次裝載。

例子
  1. pmf = (PersistenceManagerFactory) (Class.forName("com.libelis.lido.PersistenceManagerFactory").newInstance()); 
  2. pmf.setConnectionDriverName("versant"); 
  3. pmf.setConnectionURL(dbName); 
  4. pm = pmf.getPersistenceManager(); 
  5. tx = pm.currentTransaction(); 
  6. tx.begin(); 
  7. Provider aProvider = new Provider("LIBeLIS"); 
  8. pm.makerPersistent(aProvider); 
  9. Address anAddress = new Address("25 rue Paul Barruel""France""Paris"); 
  10. aProvider.address = anAddress ; 
  11. tx.commit(); // objects are stored into the data source, client cache is discarded, references are invalid 
  12. tx.begin(); 
  13. System.out.println(aProvider); // aProvider is refreshed from the data source 
  14. tx.commit(); 
  15. pm.close();

每次你修改了一個對象,它在JDO緩存中對應的實體將被標示爲“髒(dirty)”。

例子
  1. tx.begin(); 
  2. aProvider.address = aNewAdr; // aProvider is marked as dirty 
  3. tx.commit(); // aProvider will updated in the data source

在事務的結束,PersistentManager 將把所有標示爲“髒”的JDO對象(髒對象)更新到數據源中。

JDO緩存中的每一個對象都有自己的狀態(實際上它們都和一個StateManager對象相關聯)。並且JDO規範規定了一大堆狀態和它們之間的過渡。如果感興趣,請參照JDO規範瞭解詳細。
NB:這些狀態一般是JDO提供商關心的,而不是JDO編程者。
開發週期
爲了達到上面提到的完全透明的持久化,JDO定義了一個稱爲“增強(Enhancement)”的字節碼工具機制(byte-code instrumentation mechanism)。它的思想是從業務類中剔除所有的顯式的數據庫依賴代碼。和已存在的或新的數據源的映射通過外部的元數據(metadata)XML文件定義。
JDO增強器讀取編譯的java文件(.class文件),並且應用元數據文件中定義的持久化規則。例示如下:

增強會添加到元數據文件描述的類的字節碼中:
• 實現PersistentCapable接口的聲明
• 該接口中聲明的方法的字節碼必須被實現
• 當修改了一個屬性後該對象標示爲“髒”的代碼
• 需要時從數據源中獲取對象的代碼
• 根據元數據文件中指定的從數據源中的原始數據(raw data)到Java對象映射的代碼
NB:在專家小組中,是否要把增強列入JDO規範曾經激烈爭論過。一些專家認爲開發者可能會被增強技術嚇倒。不熟悉這個技術的開發者會驚訝於字節碼增強,這是一個事實。但是增強是這樣一種通用、強大的開發技術,可以在很多案例中有效地使用。開始時,每當開發者遇到一個Bug時,可能會責難增強器。我們強烈推薦增強器的“新手”仔細地看一下BCEL網站(由Source Forge開源社區提供)。在那兒,你能看到許多關於字節碼增強的有用信息和工具。這種機制的熟手可以在他們的Java接口中成功地使用。所有的熟手都表現出了興趣。

在兩層(Client/Server)結構中整合
在傳統的Client/Server體系中,JDO應用需要使用由JDO實現提供的PersistenceManagers把它自己連接到一個或多個數據源。


臨時對象可以持有持久對象的引用。持久對象可以持有分佈在多個PersistenceManagers中的持久對象的引用。但是這不是一個必須遵從的特性。
大部分數據庫相關的代碼都從業務對象中移去,但是事務仍需要編程者明確的劃分(使用Transaction 的begin、commit、rollback方法)。
管理運行在內存中的Java模型和磁盤上的數據源的物理模型之間的映射是PersistentManager的職責。當使用ODBMS時,這個映射非常直接,但使用RDBMS或更簡單的數據源時可能會非常複雜。

四、JDO和J2EE

JDO已經設計爲整合入J2EE體系。JDO依靠一個新的Connector規範來管理一個J2EE應用和JDO容器之間的交互。在JDO規範中這個描述爲管理環境(managed environments,意思是事務和連接由應用服務器自己管理)。JDO容器和J2EE應用服務器交互,得到數據源的連接(因爲應用有它自己的連接池),並根據應用服務器的JTA兼容的事務管理器執行事務。

JDO明確的解決了J2EE體系的一個主要缺陷,就是EJB部件模型將持久性和分佈性結合起來。這兩個概念是不相關的,但是EJB規範試圖簡化,迫使應用對持久性和分佈性使用相同的粒度級別。這在軟件工程的視角並不清晰,並且也不具可擴展性。
另外一點,EJB持久模型(CMP和BMP)過分簡化了,只能應付有限的情況,不適合現實的應用需要。感興趣的讀者可以可以很容易地J2EE的門戶中(例如the ServerSide)找到大量的EJB持久性和JDO的討論。
使用JDO,你可以使用一種非常優雅、通用的設計:Session Bean(訪問業務處理對象)自己訪問業務數據對象。這樣做,應用仍然擁有J2EE體系所有的優點(分佈式、事務、連接,…),並且持久化由JDO透明、高效地管理。

JDO可以支持在異種數據源中非常複雜的映射機制,然而,EJB/CMP模型僅適用於簡單的JDBC模型。
使用JDO你沒有業務對象的複雜性的限制(然而EJB/CMP不支持繼承)。
使用JDO在你的業務數據對象中完全沒有數據庫代碼(然而使用EJB/BMP 你的業務代碼會摻雜入JDBC代碼)
業務處理對象提供了處理多個業務數據對象的方法。
業務處理對象通常是非持久化的,它們通常通過混合的JDO查詢和導航得到業務數據對象。
從SessionBean中剝離業務處理方法仍然很重要,因爲這樣你的業務模型可以把衆多應用中任何的基礎構架應用到J2EE應用中。

資源鏈接


• Sun JDO Specification 
• JDO JSR page 
• Sun JDO site 
• Byte-code enhancement web sites 
• LIBeLIS LiDO site 
• Versant enJin 
發佈了74 篇原創文章 · 獲贊 2 · 訪問量 9萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章