企業級 Java 應用架構的五大核心決策點
在 J2EE 開發中，架構師面臨兩大陣營抉擇：重量級 EJB 2 路線（Session Bean、MDB、Entity Bean/DAO）與輕量級 POJO 路線（POJO 業務邏輯 + Hibernate/JDO 持久化 + Spring AOP 企業服務）。EJB 3 融合兩者特性，實體 Bean 屬輕量級，Session/MDB 仍具重量級特徵。以下系統梳理五大決策維度。
決策一：業務邏輯如何組織？
- 程序式（Transaction Script）：適用簡單邏輯，行為集中於少數大類，操作「貧血」資料物件。易開發、難維護，複雜度上升時變成惡夢。
- 物件導向（Domain Model）：豐富物件模型，狀態與行為封裝於眾多小類。需 POJO + 輕量持久化框架支援繼承、回呼等進階特性，長期維護性優。
- 表模組：每張資料表對應一個類，封裝該表所有操作。結構介於前兩者，維護性隨規模增長而下降。
決策二：業務邏輯如何封裝？
- EJB Session Facade：經典 J2EE 方案，容器提供事務、安全、遠端存取。粗粒度 API 減少網路往返，但開發測試週期長，DTO 維護繁瑣。
- POJO Facade + Spring AOP：以 POJO 替代 EJB，AOP 提供事務/安全服務。可在容器外開發測試，避免 DTO，支援依賴注入。缺點：無法參與遠端客戶端發起的分散式事務。
- 暴露領域模型：表現層直接存取領域物件，持久層透過延遲載入自動管理關聯。減少 Facade 代碼，但增加表現層複雜度，Web 環境下事務邊界控制極具挑戰。
決策三：資料庫存取策略
- 直連 JDBC：SQL 維護困難、移植性差、樣板代碼多且易錯。僅適極簡單或極度效能敏感場景。
- iBATIS (SQL Maps)：XML 映射 JavaBean 與 SQL，保留 SQL 控制權，簡化 JDBC 樣板代碼，支援緩存、延遲載入。適合既有複雜 SQL 或 DBA 強制控制 SQL 場景。
- ORM 框架：物件關係映射自動生成 SQL，提供 CRUD API、透明持久化、關聯導航。Hibernate、JDO 為主流，開發測試輕鬆，支援 POJO 豐富模型。EJB 2 Entity Bean 缺陷多已被棄用。
決策四：短交易併發控制
- 資料庫隔離等級：串行化執行，效能代價大，多避免使用。
- 樂觀鎖定：版本欄位檢查，衝突機率低時優勢明顯。ORM 框架配置即啟用，極簡單。
- 悲觀鎖定：讀取即鎖定，需資料庫支援。ORM 提供 API 實現，衝突頻繁時適用。
決策五：長交易（跨多請求）併發控制
- 樂觀離線鎖：編輯開始記錄版本，提交時比對。適用衝突罕見、用戶可接受重試場景。
- 悲觀離線鎖：編輯開始由應用層鎖定資料，防止他人修改。適合衝突成本高、需強一致性場景。
架構決策無絕對優劣，需依專案複雜度、團隊熟悉度、效能需求、部署環境綜合權衡。理解各選項的權衡點，才能做出最適合的架構選擇。
