由孫賓譯自http://www.onjava.com/pub/a/onjava/2003/05/21/jdo.html
作者：David Jordan 和 Craig Russell
著有《Java Data Objects》一書
2003年5月21日
作者注：JDO和CMP方式的EJB目前正在同時向前發展，但采取的是不同的路線。JDO的核心思想是在企業應用軟件架構的不同層面中存儲傳統的Java對象（Plain Old Java Objects，下稱POJOs），而CMP方案則基于容器環境，并針對特殊的需求。
兩者之間的異同在規范出臺之初便成為眾所爭論的話題。你可以到JDOCentral.com上看到這類的爭論，而在6月中旬即將在舊金山開幕的2003年JavaOne大會上，也會有一些演示和講解來比較這兩種不同的技術。
在這次JavaOne大會上，3368號技術對話將討論JDO與Struts（一個著名的Web應用架構設計的開源軟件）集成的可行性和實踐經驗；3236號專題研究JDO與EJB容器的結合；1289號專題將對比使用JDO、JDBC和EJB時，設計模式在開發中的應用。
在我們的《Java Data Objects》的第17章有一小段話描述使用JDO和CMP的平衡點。－－Craig Russell
JDO還是CMP？
在你對項目開發策略下決定之前，CMP實體Bean和JDO都是值得考慮的方式。
JDO對粗粒度和細粒度的數據對象設計都很適合，具體在一個應用服務器環境中，一般用于SessionBean后面。CMP也是用于SessionBean之后，它的遠程調用很少直接用到。
JDO編寫的類只須編譯一次就可用于分布式架構中的任何一層，并且在集成到Web或應用服務器之前可以以單層或兩層的方式先調試好。而CMP只能在發布到一個具體的應用服務器后才能調試。
JDO沒有直接定義遠程行為，這一點與Servlet、JSP和EJB組件不同。所有的分布處理、事務和安全方面的策略都基于獨立存儲管理器，該管理器負責處理你的對象模型中所有的類實例。這一點也說明你可以在分布式環境中的任何層面上使用JDO，而其遠程行為由容器來實現，而不是JDO廠商。
CMP組件提供了較高的可移植性，Bean類及其描述符都是規范化的。多數的不兼容性只存在于規范所未能盡述的地方，包括如何將類映射到具體的數據庫（不限于關系數據庫）、類似只讀類的可選功能、其它方面的廠商擴展。而JDO產品視具體廠商所支持的可選功能而有所不同。
CMP中，對象之間的關系是受控的，即一端的改變會影響到另一端，并且對應用是可見的。而JDO不支持關系的管理，只是一些廠商以擴展的方式提供類似功能。
繼承是對真實對象建模時常用的概念，但CMP并不支持它。CMP在組件的定義和實現時并不一致，在具體實現一個EntityBean接口時，實現的類可以具有繼承關系，但在定義這個EntityBean時卻不行。類之間的關系也只是在接口之間，而不是在實現類之間，因此這些關系也不存在多態性。舉例來說，一個名為MediaItem的CMP Bean類不能直接聯系到名為MediaContent的類，因為MediaContent是抽象的，類并無具體實例。要建立這樣的聯系，你只能將其轉換為兩個關系：一個是MediaItem與Movie類，一個是ModiaItem與Game類，并且在每個相關方法中，你必須針對兩個關系區別對待。
在訪問對象屬性上，CMP和JDO也天差地別。CMP Bean中，所有的屬性和對象關系都是作為抽象的get和set方法定義在描述符中，對實際屬性的訪問只能由具體的由相關工具生成的實現類去完成。而JDO中，可保存的屬性和關系在描述符中聲明，并且在代碼中也可以直接訪問這些屬性，包括JDO產品生成的代碼在內。JDO增強器會在增強時適當地改造這些代碼。
JDOQL和EJBQL都提供了類似的查詢數據的方法。兩者都可以在程序中查詢并訪問數據對象，都采取“讀－改－寫”的策略，都不是完整的數據操縱語言（比如沒有數據更新語句），它們都只用于查找數據對象并在代碼中訪問。
CMP要求所有的訪問操作都在事務環境中，非事務方式的訪問不受支持。而JDO允許你決定是否采用事務方式。對需要更新數據的地方，JDO要求采用事務，而只是讀取的代碼中，包括緩沖在內，JDO支持非事務方式的訪問。
David Jordan創立了Object Identity, Inc.,提供Java Data Objects（JDO）的咨詢和培訓服務。David也是《Java Data Objects》一書的作者之一，另一作者是Craig Russell。
Craig Russell是Sun微系統公司的JDO規范領導者。