背景與動機
在完成 J2EE 大型 Blog 系統與軟工 Web Design 專案兩次實戰後，歸納出一個極其順手的設計模式。雖未系統學習設計模式理論，但實踐證明：「這樣做，會很順手！」
核心架構：雙通道 MVC
圖示：UI 層雙通道調用 Session Bean 與 Action Bean
關鍵角色與職責
| 組件 | 職責 | 協作關係 |
|---|
| UI 層 (JSP/前端) |
頁面渲染、用戶交互入口 |
雙向調用 |
| Session Bean (EJB/POJO Service) |
封裝業務邏輯、事務管理、數據庫 CRUD 核心操作 |
被 UI 直接查詢；被 Action Bean 調用完成寫操作 |
| Action Bean (Struts Action/Controller) |
處理表單提交、參數校驗、流程控制、異常捕獲 |
調用 Session Bean 執行業務寫操作；返回導航結果 |
數據流向
- 查詢路徑 (Read Path)： UI → Session Bean → DB → 返回數據模型 → UI 渲染。
- 寫入路徑 (Write Path)： UI 表單提交 → Action Bean (校驗/預處理) → Session Bean (事務/業務邏輯/持久化) → DB → Action Bean 返回導航 → UI 刷新。
為何順手？
- 職責極致分離：查詢無副作用直達 Service 層，寫操作經 Controller 守門，符合 CQRS 思想雛形。
- 事務邊界清晰：Session Bean 管理事務，Action Bean 無事務邏輯污染。
- 複用度高：Session Bean 同時服務於頁面查詢與表單處理，邏輯零重複。
- 測試友善：Service 層可獨立單元測試，Action Bean 可 Mock Service 測試流程。
- 遷移平滑：Session Bean 可無縫切換 EJB / Spring POJO / CDI Bean，架構不變。
實踐建議
- Session Bean 粒度以「聚合根」或「業務領域」劃分，避免貧血模型。
- Action Bean 僅做參數綁定、校驗、調用 Service、導航，嚴禁包含業務計算。
- 引入 DTO/ViewModel 隔離領域模型與頁面結構，減少懶加載問題。
- 統一異常處理機制：Action Bean 捕獲 Service 異常轉為用戶友好提示。
結語
這個模式本質是 MVC 在 J2EE 分層架構下的最佳實踐具現：Model = Session Bean (Domain Service)，View = JSP/Frontend，Controller = Action Bean。它以最小複雜度換取最大靈活性，堪稱 J2EE 專案的「標準順手招」。
