接續上集，本文探討 Java Data Objects (JDO) 與 無狀態 Session Bean 的組合，並與標準實體 Bean 方案正面對決。JDO 作為 J2EE 最新持久化方案，以「純物件導向、極致簡單」著稱，能否撼動實體 Bean 的霸主地位？
JDO 核心觀念：POJO 持久化
傳統持久化機制多為關聯式（表/欄位），與物件導向（封裝、引用、繼承）阻抗失配嚴重。JDO 讓開發者：
- 直接用 Java 語言持久化/檢索物件實例
- 邏輯、同步、故障轉移透明處理
- 無需 SQL 或繁瑣序列化，僅操作 POJO（Plain Ordinary Java Object）
- 可插拔架構：標準 JDO API + 供應商實作，易移植、促進競爭
Session Bean + JDO 運作機制
- Session Bean 透過 JNDI 取得
PersistenceManagerFactory
- 從工廠獲取
PersistenceManager 實例
- 容器管理交易：每業務方法獲取新 PM，方法結束前關閉
- Bean 管理交易：開發者控制交易邊界，可跨方法復用 PM
核心 API 極簡直觀
makePersistent(obj)：物件持久化（支援單一/陣列/集合）getObjectById(id)：主鍵查詢- 型別查詢：依介面/父類檢索物件集合
- 交易控制：
begin()/commit()/rollback()，支援樂觀/悲觀鎖
Session Bean + JDO 三大優勢
| 優勢 | 來源 | 說明 |
|---|
| 設計簡單 | Session Bean | 架構層面比實體 Bean 簡單得多 |
| 細粒度控制 | 完整掌控快取、持久化、併發、同步 |
| 編碼簡單 | JDO | 隱藏底層持久化細節，專注業務物件管理 |
| 生產力提升 | 純 OO 範式，避免關聯/物件思維切換 |
| 物件導向持久化 | 透明持久化整個物件圖、型別階層、支援多型查詢 |
兩大致命短板
- JDO 不成熟：規範發布不足一年，社群小、缺乏實戰模式/案例、企業級採用風險高
- Session Bean 非交易性：JDO 物件雖可宣告交易，但入口為非交易性 Servlet/Session Bean，開發者須自行在程式碼中確保業務規則、流程控制、交易完整性。容器管理交易雖緩解此問題，但犧牲了交易粒度控制靈活性
實體 Bean 回顧：優缺點對照
五大優勢
- 標準化成熟：豐富設計模式、案例、工具、人才庫
- 容器管理服務：安全、交易、連線池、資源管理全包辦
- 透明持久化：CMP 全自動，BMP 寫邏輯但容器管完整性/併發
- 交易支援：CMP 宣告式、BMP 程式化，容器統管提交/回滾
- 元件化設計：部署描述符配置，零程式碼修改跨伺服器部署
四大缺點
- 設計複雜：黑盒容器行為不可預測，需大量場景測試
- 構建週期長：比同級 Java 持久化方案久 2-3 倍
- 回應時間：受限於 Bean 顆粒度，大實體查詢慢，拆小則架構更複雜
- 資源佔用大：佔用大量系統資源
關鍵對比維度
| 維度 | 實體 Bean | JDO |
|---|
| 共同特性 | 透明持久化、可移植性、彈性交易管理 |
| 最佳實踐 vs 簡單性 | 豐富資產但複雜度高，需資深專家平衡 | 以簡單性彌補最佳實踐匱乏，易上手 |
| 舊系統支援 | 完美整合現有 RDBMS | 主流 RDBMS 廠商未支援，需遷移或限用於新專案 |
| 持久化範式 | 關聯式 | 物件導向（合成、繼承、完整型別階層），DBA 適應困難 |
| 資源使用 | 高 | 預期較低（缺乏基準測試） |
三大持久化技術總結
- JDBC：成熟標準，利用現有 RDBMS 基礎設施與 SQL 專長，缺點是開發者自管併發/完整性，但因普及度高廣泛使用
- 實體 Bean：容器承擔生命週期服務，簡化健壯持久化代碼開發，代價是資源密集、配置複雜、除錯困難
- JDO：純 OO 方法、設計簡單、適應期最短，但缺乏成熟生態，要求 DBA 學習全新管理範式
結語
J2EE 提供三種可靠持久化技術，無完美銀彈。選型需權衡：團隊專長、既有基礎設施、專案時程、擴展性需求、維護成本。下月將探索企業訊息傳遞，結束 EJB 領域首輪探險——祝探險愉快！
