兩大實現路徑對比
| 維度 | 重量級（EJB 2.x） | 輕量級（POJO + 框架） |
|---|
| 業務邏輯 | Session Bean / MDB | 純 POJO（領域模型） |
| 資料存取 | Entity Bean / DAO | Hibernate / JDO / iBATIS |
| 企業服務 | EJB 容器（事務、安全、遠程） | Spring AOP（聲明式事務、安全） |
| 測試部署 | 需容器，週期長 | 容器外可測試，輕量快速 |
EJB 3 融合兩者：Entity Bean 變輕量（可脫容器運行），Session/MDB 仍需容器。
五大關鍵架構決策
- 業務邏輯組織：面向對象（領域模型）vs 面向過程（事務腳本/表模組）。複雜領域首選領域模型，需 POJO + 輕量級持久層支援繼承、回調等豐富行為。
- 業務邏輯封裝：
Session Facade（EJB）：容器提供事務/安全/遠程，粗粒度 API 減少網路往返，但開發測試慢、需 DTO。POJO Facade + Spring AOP：同樣封裝優勢，開發測試快、無 DTO、依賴注入替代 JNDI，但無法參與遠程分散式事務。- 暴露領域模型：直接將模型交給表現層，配合 Lazy Loading 減少 Facade 代碼，但增加表現層複雜度與事務管理難度。
- 資料庫存取：
- JDBC：樣板代碼多、SQL 維護難、移植性差。
- iBATIS：XML 映射 SQL，消除 JDBC 瑣碎代碼，保留 SQL 控制權。
- ORM（Hibernate/JDO）：物件關係映射，自動生成 SQL、透明持久化、支援繼承/關聯/快取/延遲載入，開發體驗最佳。
- 單一資料庫事務並發：
- 隔離事務（Serializable）：簡單但效能差。
- 樂觀鎖（版本欄）：衝突少時優選，ORM 設定即啟用。
- 悲觀鎖（資料庫鎖/應用鎖）：衝突頻繁時使用，需資料庫支援。
- 長業務事務並發（跨多個 DB 事務）：
- 樂觀離線鎖：編輯開始記錄版本，提交時檢查。適合衝突少、用戶可接受重試。
- 悲觀離線鎖：編輯開始即鎖定資源，獨佔編輯權。適合衝突頻繁、不可重試場景。
決策建議
- 多數新專案首選 POJO + Spring + Hibernate/JDO，開發效率與維護性最佳。
- 需遠程分散式事務、嚴格企業級安全合規時考慮 EJB 3 Session Bean。
- Legacy 系統整合、極致 SQL 控制需求可採 iBATIS。
- 並發策略視業務衝突頻率與用戶體驗權衡選擇。
