J2EE 業務邏輯與資料存取架構決策：EJB vs POJO 全方位比較

兩大陣營：重量級 EJB vs 輕量級 POJO

EJB 3 融合 POJO 概念 (Entity Bean 即 JPA Entity)，但 Session/MDB 仍綁定容器，屬混合模式。

決策一：業務邏輯組織 — 面向過程 vs 領域模型

交易腳本 — 面向過程

• 每個用戶操作對應一個 processXxx() 方法，內含完整 SQL/邏輯。
• 資料物件為「貧血」 DTO (僅 getter/setter)。
• 適合：邏極簡單、CRUD 為主、團隊缺乏 OO 經驗。
• 缺點：邏輯重複、難維護、無法應對複雜業務規則。

領域模型 — 面向物件

• 豐富領域物件封裝狀態與行為：order.calculateTotal()、account.transfer()。
• 關係網絡表達業務規則 (聚合、值物件、領域服務)。
• 需 ORM (Hibernate/JPA) 支援持久化、延遲載入、繼承映射。
• 適合：複雜業務、長期演進、核心競爭力在業務邏輯。

表模組 — 折衷

• 每張表對應一個類，封裝該表所有操作。
• 優於交易腳本 (資料行為封裝)，遜於領域模型 (無法跨表表達業務不變量)。

決策二：業務邏輯封裝 — Facade 模式比較

決策三：資料存取技術選型

建議：核心領域用 ORM，複雜報表/批次用 MyBatis/JDBC，混合使用。

決策四：短交易併發控制

• 資料庫隔離等級：Serializable 最嚴格但效能差，Read Committed 最常用。
• 樂觀鎖：@Version 欄位 + WHERE version = ?，適合低衝突、高併發讀。ORM 內建支援。
• 悲觀鎖：SELECT ... FOR UPDATE，適合高衝突、需強一致性。資料庫支援度不一。

決策五：長交易 (用戶交互跨多請求) 併發控制

長交易不可使用資料庫原生鎖 (跨請求無法持有連線)，必須在應用層實作。

決策矩陣：如何選擇？

1. 團隊技能：熟悉 Spring/Hibernate → POJO 路線；熟悉 EJB/應用伺服器 → EJB 路線。
2. 專案性質：企業級分散式、異構整合、嚴格交易 → EJB；Web 應用、微服務、快速迭代 → POJO。
3. 基礎設施：已有 WebLogic/WebSphere 授權 → EJB 成本較低；雲原生/Kubernetes → Spring Boot/Kotlin 更適合。
4. 長期演進：POJO 架構靈活性高，易拆分微服務；EJB 遷移成本大。

結語

沒有銀彈，只有權衡。現代趨勢明確傾向 POJO + Spring 生態 + 容器化部署，但理解 EJB 設計哲學 (聲明式服務、遠端透明、容器管理) 有助於在任何框架下做出正確架構決策。