前言：EJB 3.0 的設計哲學
EJB 3.0 以「開發簡易性」為核心，由 Linda DeMichiel 主導規格制定，廣泛吸收社群意見並借鑑 TopLink 等成熟產品經驗。這使得規範不再閉門造車，而是順應業界公認的最佳實踐演進。對開發者而言，擁抱 EJB 3.0 不僅是升級 API，更是重新審視架構與開發模式的契機。
一、 夯實架構基礎：標準化持久層與分層設計
- 採用成熟設計模式：Session Facade、DAO（Data Access Object）層、Service Layer 等模式在 EJB 3.0 中從「建議」變為「關鍵」。它們能隔離業務邏輯與持久化細節，確保應用經得起時間考驗。
- 拒絕遠端實體：若現有系統以 Remote Entity Bean 為核心（雖罕見），必須重構。實體應為本地，持久化操作前置於可遠端化的 Service Layer。
- 事務與安全下沉：EJB 3.0 實體層不再支援宣告式事務/安全屬性，這些責任轉移至調用者（Session Bean、Web 組件等），由外層容器管理運行環境。
二、 CMP 遷移：從繁瑣到輕量
若你是 CMP（Container-Managed Persistence）老手，EJB 3.0 將解脫你於：
- 無關介面（Remote/Local Interface）與
EJBObject/EJBLocalObject 繼承體系。
- 冗長的 XML 部署描述符。
- 實體類現在只需實作 POJI（Plain Old Java Interface），甚至可為純 POJO，直接用
new Entity() 實例化，支援容器外測試。
三、 POJO 風格持久化：EntityManager 核心角色
- EntityManager 代表事務性持久化上下文，可透過
@PersistenceContext 注入 Session Bean，或經 JNDI 查詢取得。
- 受管理實體在事務結束時若處於「髒狀態」，變更自動同步至資料庫。
- 依賴注入範式：應用程式宣告所需資源（DataSource、EntityManager 等），運行期由容器注入，達到鬆耦合與可測試性。
四、 採用標準化查詢與映射功能
EJB QL / JPQL
查詢語言是遷移痛點，但 EJB QL 以抽象關聯式 SQL 為優勢，EJB 3.0 進一步增強功能。建議盡早以 EJB QL 撰寫查詢，語法穩定且向前相容。
原生 SQL 查詢
少數需直接操作 SQL 時，可建立 Native SQL Query，仍能映射回實體物件。
五、 真正的繼承支援
EJB 2.1 缺乏自然繼承機制，EJB 3.0 透過 POJO 本質，支援任意深度/廣度的實體繼承階層（單表、聯表、具體表等策略）。現可透過 TopLink Mapping Workbench、JDeveloper 等工具先行建模，不必等待最終規範發布。
六、 樂觀鎖定：高併發與離線場景的利器
- 機制：每個實體擁有版本欄位（數值或時間戳），更新時比對版本，衝突則拋出
OptimisticLockException。
- 效能優勢：讀/寫比 90:10 典型場景下，避免悲觀鎖的資料庫鎖開銷，大幅提升擴展性。
- 離線支援：非連接模式下，實體可在客戶端修改，重新併入事務時透過版本驗證是否為失效副本，完美適配 Web 應用的長會話場景。
七、 物件關聯映射（ORM）標準化
EJB 3.0 引入標準化映射元數據（Annotations / XML），涵蓋：
- 基本型別轉換
- 一對一、一對多、多對多關聯
- 繼承映射策略
- 嵌入式物件、集合映射等
未來將擴充進階映射功能，目標是讓應用程式在不同資料庫、持久化框架間可攜遷移。
結語
EJB 3.0 不只是 API 更新，更是推動 Java EE 開發走向「慣例優於配置」、「POJO 為本」的里程碑。提前佈局架構重構、領域模型建模、查詢語言標準化，將讓你在正式版釋出時無縫切換，搶占開發效能與系統品質的雙重紅利。
