您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> Java 相關知識

JDO vs CMP 2.x 技術選型深度對比：POJO 持久化 vs 容器管理實體 Bean 的架構抉擇

編輯：Java 相關知識

前言：兩種持久化哲學的對決

2003 年 JavaOne 大會上，JDO 與 CMP 之爭成為焦點。本文基於 David Jordan 與 Craig Russell 合著《Java Data Objects》第 17 章核心觀點，結合 JDO 1.0 與 EJB 2.1 CMP 規範特性，為架構師提供決策框架。

核心架構差異

維度	JDO (Java Data Objects)	CMP (Container-Managed Persistence)
核心哲學	POJO 持久化：純 Java 物件透明持久化	元件模型：實體 Bean 作為分散式元件
執行環境	任意層（單層、雙層、多層、EJB 容器內/外）	強制 EJB 容器內，Session Bean 後方
遠程介面	無直接定義，由容器/框架實現分散式行為	原生遠程/本地介面，容器管理分散式語義
開發除錯	部署前可單元測試，IDE 友好	需部署至應用伺服器才能測試，週期長
可移植性	視廠商可選功能支援度而異	Bean 類與描述檔標準化，移植性較高

關鍵技術能力對比

1. 物件關係映射與繼承支援

JDO：原生支援繼承映射（單表、類別表、具體類別表策略），多型查詢、多型關聯自然表達
CMP 2.x：不支援繼承。實作類可繼承，但元件介面定義不支援。抽象父類無法映射為關聯目標，需拆解為多個具體關聯，程式碼冗餘且失去多型性

範例：MediaItem 關聯抽象 MediaContent 及子類 Movie、Game。CMP 必須建立兩個獨立關聯，每個業務方法雙重處理。

2. 關聯關係管理

CMP：容器管理關聯（CMR）——雙向關聯自動維護，一端變更即時反映另一端，應用可見
JDO：規範不強制關聯管理，部分廠商以擴充功能提供類似能力

3. 屬性存取與程式碼風格

CMP：所有屬性/關聯定義為抽象 get/set 方法，實際存取由工具生成的實作類完成，原始碼中無法直接存取欄位
JDO：描述檔宣告可持久欄位，程式碼可直接存取欄位（含增強後代碼），增強器自動織入持久化邏輯

4. 查詢語言：JDOQL vs EJB QL

特性	JDOQL	EJB QL
語法基礎	Java 語法子集，型別安全	SQL 類似語法，字串基礎
查詢對象	持久化類與欄位直接引用	實體 Bean 抽象綱要名稱
多型查詢	原生支援	不支援（因無繼承）
導航路徑	物件圖導航自然表達	關聯路徑導航
批次更新/刪除	JDO 2.0 引入	EJB 3.0 / JPA 引入

兩者皆採「讀-改-寫」模式，非完整 DML，主要用於查找物件後在記憶體中修改再持久化。

5. 事務與非事務存取

CMP：強制事務環境，非事務存取不支援
JDO：靈活選擇——更新操作需事務，唯讀/快取可非事務存取，效能更優

架構決策矩陣：何時選擇哪一個？

選擇 JDO 的場景

領域模型豐富、大量繼承與多型：領域驅動設計（DDD）核心領域層
需單元測試驅動開發 (TDD)：POJO 可脫容器測試，快速反饋
多層架構共享領域模型：Web 層、批次層、EJB 層共用同一組領域類
輕量級部署/嵌入式場景：無完整 EJB 容器環境
遷移既有 JDBC/Hibernate 應用：程式碼改動最小

選擇 CMP 的場景

標準化分散式元件介面：異構系統整合、遠程客戶端直接呼叫實體 Bean
複雜雙向關聯自動維護需求強：容器管理關聯減少應用層同步邏輯
嚴格 J2EE 標準合規要求：採購規範要求標準 API、可移植性優先
已投入 EJB 生態、團隊熟悉 CMP 工具鏈：XDoclet、EJB 設計工具成熟

融合趨勢：EJB 3.0 / JPA 的統一

歷史證明，JDO 的 POJO 哲學與 CMP 的容器服務最終在 EJB 3.0 (JPA) 中融合：

JPA 採用 JDO 風格的 POJO 實體類、註解配置、EntityManager API
保留 CMP 風格的容器管理事務、安全、遠程、依賴注入
JDO 專家組核心成員（Craig Russell 等）主導 JPA 規範制定
Kodo (BEA) 同時實作 JDO 與 JPA，證明技術路線可相容

總結

JDO 贏在「物件純粹性、開發敏捷性、測試友好、繼承多型」；CMP 贏在「分散式元件語義、關聯自動管理、標準化移植性」。2003 年的選擇本質是：領域模型中心 vs 元件介面中心。現代架構中，JPA 已成為事實標準，但理解這場歷史辯論有助於把握持久化框架設計的核心權衡——純粹物件模型與容器服務的邊界在哪裡？ 這正是每個架構師必須回答的問題。