Struts + Hibernate 架構下的 J2EE 分層資料表示最佳實踐

核心觀點

在 Struts + Hibernate 架構中，**切勿將 Hibernate 產生的 PO (持久化物件) 直接傳遞給 JSP**，無論是 Iterator、List 或單一物件，這都是設計錯誤。J2EE 分層架構要求各層資料表示物件應限制在層內，不應跨層流動，以降低耦合、提升可維護性與擴展性。

各層資料表示定義

Hibernate 的強大功能 (動態生成 PO、脫離 Session 的狀態管理) 使 PO 可充當 VO，故下文將 PO 與 VO 合稱 PO。

ActionFormBean 與 PO 的根本差異

簡單應用：看似相同

許多開發者直接用 ActionFormBean 當 PO，形成「一竿子捅到底」的反模式：JSP → Servlet → Service → DAO → DB，任何頁面異動都波及全系統。

複雜應用：必然分離

• 對應關係不同：Form Bean 對應 HTML 表單欄位 (一對一)；PO 對應資料庫表結構
• 屬性結構不同：PO 擁有集合屬性 (權限、群組、文章等)，Form Bean 沒有；Form Bean 可能拆分為多欄位 (First/Middle/Last Name)，PO 則合併為單一 Name 物件
• 變更頻率不同：頁面流程調整只改 Form Bean，資料庫結構不變則 PO 不動

具體範例：用戶註冊

• Form Bean：包含 firstName、middleName、lastName 三欄位，對應三個輸入框
• PO (User)：單一 Name 物件屬性，另含 permissions、groups、posts 等集合屬性
• 變更場景：頁面新增 middleName、lastName 欄位 → 修改 Form Bean；資料庫無變動 → PO 不動

正確的分層資料流向

JSP (View) 
  → ActionFormBean (Web Module) 
  → Action (Control) 
    ├─ 讀取 FormBean 屬性
    ├─ 組裝 PO 物件
    ├─ 呼叫 Business Bean (業務層)
    │    └─ 呼叫 DAO → ORM → DB
    └─ 取回 PO → 組裝 FormBean → request.setAttribute → 轉向結果頁
JSP 透過 Tag 顯示 FormBean

查詢流程範例

1. 用戶輸入全名查詢 → Action 取得 UserNameFormBean (first/middle/lastName)
2. Action 組裝 Name 物件 → 呼叫 Business Bean
3. Business Bean 呼叫 DAO → 回傳 User PO (含集合屬性)
4. Action 從 User PO 取基本屬性 → 組裝 UserFormBean → 放入 request → 轉向頁面

設計原則總結

1. Form Bean 為 Web 層專屬，不得傳遞至業務層/持久層
2. PO 為業務/持久層專屬，最多到達 Web 層 Control (Action)，絕不可到 View (JSP)
3. Form Bean ↔ PO 轉換在 Action 中進行，作為層間轉換邊界
4. Hibernate 環境下 PO 可兼任 VO，但仍須遵守層邊界限制

違反原則的後果

• 頁面微調引發全鏈路代碼修改，維護成本指數級上升
• View 直接存取 PO 的集合屬性導致 LazyInitializationException 或效能問題 (N+1 查詢)
• 業務邏輯耦合表單結構，無法複用於非 Web 介面 (如 Web Service、批次作業)