原文：
http://www.libelis.com/inner-index.jsp?next=jdo.htmlJDO是Java對象持久化的新的規(guī)范。JDO經(jīng)SunJava Community Process認定。
一、歷史
JDO是對象持久化工作的綜合成果，試圖提供一個對象持久化的完全版本。JDO同時繼承于ODMG（對象數(shù)據(jù)管理小組，標準化對象數(shù)據(jù)庫的一個獨立委員會）和對象關(guān)系映射工具提供商。
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
二、目標
定義對象級的持久化。
- 完全支持對象模型，包括引用、集合、接口、繼承
- 完全透明持久化：這使得業(yè)務(wù)對象完全獨立于任何數(shù)據(jù)庫技術(shù)，這使用了一個字節(jié)碼增強機制（a byte-code enhancement mechanism）。
- 縮短開發(fā)周期（不再需要映射）
- 在開發(fā)小組中清晰地劃分業(yè)務(wù)人員和數(shù)據(jù)庫人員。
- 通用持久性
? JDBC限于RDBMS，JDO潛在地可以處理任何類型的數(shù)據(jù)源，包括RDBMS，ODBMS，TP監(jiān)控處理，ASCII無格式文件，xml文件，properties文件，大機上的Cobol數(shù)據(jù)庫，等
? JDO是面向大型信息系統(tǒng)的一個完全的解決方案，在這樣的系統(tǒng)中，信息存儲于多種異質(zhì)數(shù)據(jù)源
- 涵蓋J2EE、J2SE、J2ME的廣泛實現(xiàn)
- 強壯的事務(wù)模型
- 同時支持C/S和多層體系結(jié)構(gòu)
三、體系
JDO 包
PersistentCapable：擁有持久實例的類必須實現(xiàn)這個接口。管理對象生命周期。
PersistenceManager ：代表了到數(shù)據(jù)源的連接。一個應(yīng)用可以打開一個或多個PersistenceManagers。
PersistenceManagerFactory：允許從數(shù)據(jù)源中得到一個PersistenceManager的實例，這個工廠也可以作為一個連接池。
Transaction：允許界定事務(wù)
Query ：允許明確地聲明性地使用JDO查詢語言從數(shù)據(jù)源中獲取數(shù)據(jù)。NB：也可以通過引用之間的基本的定位，隱含地、透明地從數(shù)據(jù)源中獲取對象。
InstanceCallback：在數(shù)據(jù)庫操作中（比如before/after read, before/after write，等），定義一些鉤子，以做特殊處理（像暫時屬性的初始化）。
JDOException：JDO操作中拋出的例外。
JDO也定義了幫助類，對象標識（由應(yīng)用或數(shù)據(jù)源管理）
JDO實現(xiàn)可以支持或不支持兼容的PersistenceManager（當PersistenceManager是兼容的時，你可以得到存儲于不同數(shù)據(jù)庫的對象引用）。
NB：在JDO的第一個發(fā)布版本中，并沒有嚴格地定義鎖和鎖策略。
JDO對象模型
- JDO對象模型基本上是Java的對象模型，包括所有的基本類型，引用，集合和事件接口。
- 除了系統(tǒng)定義類（system-defined classes），支持所有的字段類型（包括簡單型、可變和不變的對象類型〔immutable and mutable object types〕、用戶定義類、數(shù)組、集合、接口）。
- 支持所有的成員變量修飾符（private, public, protected, static, transient, abstract, final, synchronized, volatile）
- 除了對象狀態(tài)依賴于不可訪問的或遠程對象，即繼承于java.net.SocketImpl、本地方法等，所有的用戶定義類都可以是PersistentCapable。
JDO對象生命周期
為了能夠在數(shù)據(jù)源中訪問、存儲對象，應(yīng)用必須首先得到一個或幾個數(shù)據(jù)源的連接。一個JDO PersistenceManager對象就代表了這樣一個連接。它可以通過PersistenceManagerFactory類得到。持久化對象必須是實現(xiàn)了PersistentCapable接口的類的實例。這樣的類可能同時擁有持久化的或臨時的（transient）實例。
為了使一個實例持久化，編程者必須調(diào)用PersistentManager的makePersistent方法。通知JDO對象為持久化或臨時的很重要，即使它們可以從JDO的行為中得到它是臨時的，比如事務(wù)管理和對象標識。對象標識可以由應(yīng)用管理，或者由數(shù)據(jù)源代理（這大多是在使用ODBMS實例時，因為概念ObjectID本身就是ODMG模型的一部分）。
JDO支持一種持久化模型，這這種模型中持久性自動傳播到引用的對象。這種機制經(jīng)常稱為“延伸持久（persistence by reachability）”或者“傳遞持久（transitive persistence）”。這意味著一旦一個已經(jīng)持久化的對象引用了一個臨時對象，這個臨時對象自動變成持久化的。對于JDBC編程者，這個模型可能很奇怪，但是他們會發(fā)現(xiàn)這是大多數(shù)情況下編程者希望從持久化框架中得到的支持。
例子：
pmf = (PersistenceManagerFactory) (Class.forName("com.libelis.lido.PersistenceManagerFactory").newInstance());
pmf.setConnectionDriverName("versant");
pmf.setConnectionURL(dbName);
pm = pmf.getPersistenceManager();
tx = pm.currentTransaction();
tx.begin();
Provider aProvider = new Provider("LIBeLIS");
pm.makerPersistent(aProvider); // aProvider now persists
Address anAddress = new Address("25 rue Paul Barruel", "France", "Paris");
aProvider.address = anAddress ; // anAddress now persists
tx.commit();
pm.close();
對象或者通過明確的JDO查詢結(jié)果從內(nèi)存中得到，或者通過標準的Java對象之間的導(dǎo)航（navigation）得到。
最后這個機制很強大，你可以把持久對象想像為在JVM堆中的一個特殊的部分，我們稱之為“客戶端緩存（client cache）”。每次當你企圖從一個對象導(dǎo)航到另一個時，如果這個對象尚不在內(nèi)存中，JDO會自動從數(shù)據(jù)源中獲取，并把它放在緩存中。
例子
假設(shè)aProvider對象已經(jīng)裝載到內(nèi)存，但是它的Address對象還沒有。當你寫下如下代碼時：
System.out.println(aProvider.address.city);
Address對象會自動裝載。緩存管理自動鏈接到事務(wù)邊界（transaction boundaries），這意味著緩存將在事務(wù)結(jié)束是刷新，所有的實體都標示為無效的。下次對象訪問它們的狀態(tài)時，自動地、透明地從數(shù)據(jù)源中再次裝載。
例子
pmf = (PersistenceManagerFactory) (Class.forName("com.libelis.lido.PersistenceManagerFactory").newInstance());
pmf.setConnectionDriverName("versant");
pmf.setConnectionURL(dbName);
pm = pmf.getPersistenceManager();
tx = pm.currentTransaction();
tx.begin();
Provider aProvider = new Provider("LIBeLIS");
pm.makerPersistent(aProvider);
Address anAddress = new Address("25 rue Paul Barruel", "France", "Paris");
aProvider.address = anAddress ;
tx.commit(); // objects are stored into the data source, client cache is discarded, references are invalid
tx.begin();
System.out.println(aProvider); // aProvider is refreshed from the data source
tx.commit();
pm.close();
每次你修改了一個對象，它在JDO緩存中對應(yīng)的實體將被標示為“臟（dirty）”。
例子
tx.begin();
aProvider.address = aNewAdr; // aProvider is marked as dirty
tx.commit(); // aProvider will updated in the data source
在事務(wù)的結(jié)束，PersistentManager 將把所有標示為“臟”的JDO對象（臟對象）更新到數(shù)據(jù)源中。
JDO緩存中的每一個對象都有自己的狀態(tài)（實際上它們都和一個StateManager對象相關(guān)聯(lián)）。并且JDO規(guī)范規(guī)定了一大堆狀態(tài)和它們之間的過渡。如果感興趣，請參照JDO規(guī)范了解詳細。
NB：這些狀態(tài)一般是JDO提供商關(guān)心的，而不是JDO編程者。
開發(fā)周期
為了達到上面提到的完全透明的持久化，JDO定義了一個稱為“增強（Enhancement）”的字節(jié)碼工具機制（byte-code instrumentation mechanism）。它的思想是從業(yè)務(wù)類中剔除所有的顯式的數(shù)據(jù)庫依賴代碼。和已存在的或新的數(shù)據(jù)源的映射通過外部的元數(shù)據(jù)（metadata）XML文件定義。
JDO增強器讀取編譯的java文件（.class文件），并且應(yīng)用元數(shù)據(jù)文件中定義的持久化規(guī)則。例示如下：
增強會添加到元數(shù)據(jù)文件描述的類的字節(jié)碼中：
• 實現(xiàn)PersistentCapable接口的聲明
• 該接口中聲明的方法的字節(jié)碼必須被實現(xiàn)
• 當修改了一個屬性后該對象標示為“臟”的代碼
• 需要時從數(shù)據(jù)源中獲取對象的代碼
• 根據(jù)元數(shù)據(jù)文件中指定的從數(shù)據(jù)源中的原始數(shù)據(jù)（raw data）到Java對象映射的代碼
NB：在專家小組中，是否要把增強列入JDO規(guī)范曾經(jīng)激烈爭論過。一些專家認為開發(fā)者可能會被增強技術(shù)嚇倒。不熟悉這個技術(shù)的開發(fā)者會驚訝于字節(jié)碼增強，這是一個事實。但是增強是這樣一種通用、強大的開發(fā)技術(shù)，可以在很多案例中有效地使用。開始時，每當開發(fā)者遇到一個Bug時，可能會責(zé)難增強器。我們強烈推薦增強器的“新手”仔細地看一下BCEL網(wǎng)站（由Source Forge開源社區(qū)提供）。在那兒，你能看到許多關(guān)于字節(jié)碼增強的有用信息和工具。這種機制的熟手可以在他們的Java接口中成功地使用。所有的熟手都表現(xiàn)出了興趣。
在兩層（Client/Server）結(jié)構(gòu)中整合
在傳統(tǒng)的Client/Server體系中，JDO應(yīng)用需要使用由JDO實現(xiàn)提供的PersistenceManagers把它自己連接到一個或多個數(shù)據(jù)源。
臨時對象可以持有持久對象的引用。持久對象可以持有分布在多個PersistenceManagers中的持久對象的引用。但是這不是一個必須遵從的特性。
大部分數(shù)據(jù)庫相關(guān)的代碼都從業(yè)務(wù)對象中移去，但是事務(wù)仍需要編程者明確的劃分（使用Transaction 的begin、commit、rollback方法）。
管理運行在內(nèi)存中的Java模型和磁盤上的數(shù)據(jù)源的物理模型之間的映射是PersistentManager的職責(zé)。當使用ODBMS時，這個映射非常直接，但使用RDBMS或更簡單的數(shù)據(jù)源時可能會非常復(fù)雜。
四、JDO和J2EE
JDO已經(jīng)設(shè)計為整合入J2EE體系。JDO依靠一個新的Connector規(guī)范來管理一個J2EE應(yīng)用和JDO容器之間的交互。在JDO規(guī)范中這個描述為管理環(huán)境（managed environments，意思是事務(wù)和連接由應(yīng)用服務(wù)器自己管理）。JDO容器和J2EE應(yīng)用服務(wù)器交互，得到數(shù)據(jù)源的連接（因為應(yīng)用有它自己的連接池），并根據(jù)應(yīng)用服務(wù)器的JTA兼容的事務(wù)管理器執(zhí)行事務(wù)。
JDO明確的解決了J2EE體系的一個主要缺陷，就是EJB部件模型將持久性和分布性結(jié)合起來。這兩個概念是不相關(guān)的，但是EJB規(guī)范試圖簡化，迫使應(yīng)用對持久性和分布性使用相同的粒度級別。這在軟件工程的視角并不清晰，并且也不具可擴展性。
另外一點，EJB持久模型（CMP和BMP）過分簡化了，只能應(yīng)付有限的情況，不適合現(xiàn)實的應(yīng)用需要。感興趣的讀者可以可以很容易地J2EE的門戶中（例如the ServerSide）找到大量的EJB持久性和JDO的討論。
使用JDO，你可以使用一種非常優(yōu)雅、通用的設(shè)計：Session Bean（訪問業(yè)務(wù)處理對象）自己訪問業(yè)務(wù)數(shù)據(jù)對象。這樣做，應(yīng)用仍然擁有J2EE體系所有的優(yōu)點（分布式、事務(wù)、連接，…），并且持久化由JDO透明、高效地管理。
JDO可以支持在異種數(shù)據(jù)源中非常復(fù)雜的映射機制，然而，EJB/CMP模型僅適用于簡單的JDBC模型。
使用JDO你沒有業(yè)務(wù)對象的復(fù)雜性的限制（然而EJB/CMP不支持繼承）。
使用JDO在你的業(yè)務(wù)數(shù)據(jù)對象中完全沒有數(shù)據(jù)庫代碼（然而使用EJB/BMP 你的業(yè)務(wù)代碼會摻雜入JDBC代碼）
業(yè)務(wù)處理對象提供了處理多個業(yè)務(wù)數(shù)據(jù)對象的方法。
業(yè)務(wù)處理對象通常是非持久化的，它們通常通過混合的JDO查詢和導(dǎo)航得到業(yè)務(wù)數(shù)據(jù)對象。
從SessionBean中剝離業(yè)務(wù)處理方法仍然很重要，因為這樣你的業(yè)務(wù)模型可以把眾多應(yīng)用中任何的基礎(chǔ)構(gòu)架應(yīng)用到J2EE應(yīng)用中。
資源鏈接
• Sun JDO Specification
• JDO JSR page
• Sun JDO site
• Byte-code enhancement web sites
• LIBeLIS LiDO site
• Versant enJin
摘自：http://www.javaresearch.org/article/showarticle.jsp?column=108&thread=2406