Seam 不僅是 Web 框架，而是整合 Java EE 技術棧的「應用堆疊」。本文基於《Seam In Action》第一章核心概念，系統整理 Seam 整合架構、上下文元件模型、核心競爭力與適用性評估。
傳統架構：JSF Backing Bean → Service Layer → DAO (需大量轉接代碼)
Seam 架構：EJB3 Session Bean 直接作為 JSF Managed Bean，表現層與業務層無縫銜接
Seam 提供 7 種上下文範圍，其中 2 種為 Seam 獨有：
| 上下文類型 | 生命週期 | 用途 |
|---|---|---|
| Event | 單一 HTTP 請求 | 請求級資料 |
| Page | 頁面導航期間 | 跨請求頁面狀態 |
| Conversation | 使用者工作單元 | 長對話狀態管理 (Seam 獨有) |
| Session | HTTP Session | 使用者會話資料 |
| Business Process | jBPM 流程實例 | 業務流程狀態 (Seam 獨有) |
| Application | ServletContext | 全域共享資料 |
| Stateless | 無狀態 | 服務類元件 |
統一提供：元件註冊、註解驅動、異常處理、方法攔截、統一 EL 表達式
Seam 對 JSF 的關鍵增強：
faces-config.xml Managed Bean 宣告 (使用 @Name)
Conversation Context 將 Stateful EJB 引入 Web 開發，解決 HTTP 無狀態限制。
Spring 的 OpenSessionInViewFilter 僅跨單一請求，Seam 擴展持久化上下文可跨越多個請求 (Conversation 範圍)，為長對話提供基礎支撐。
| 優勢 | 挑戰 |
|---|---|
| 整合 Java EE 全棧技術 | 學習曲線極陡峭 (JSF/EJB3/JPA 新技術並存) |
| Conversation 模型解決狀態管理 | 文檔相對稀少，新手上手困難 |
| 豐富內建功能減少整合工作 | EAR 多模組專案結構增加小團隊維護負擔 |
| 開發工具支援代碼生成 | 工具穩定性有待加強 |
Seam 適合：技術實力強、專案規模大、需長對話/業務流程管理的企業級應用。
中小團隊或簡單專案建議評估 Spring MVC + JPA/Hibernate 等輕量方案。
