JBoss Seam 學習系列完結篇：為何放棄 JSF/Seam 轉向 Struts2

JBoss Seam 學習心得總結：技術選型的深度反思

經歷 JSF 專案實戰與 Seam 深度學習後，結合 Struts2 對比評估，最終決定團隊放棄 JSF/Seam 技術棧。本文詳細分析 JSF 核心痛點、Seam 整合複雜度與團隊技術決策考量。

JSF 兩大致命傷

1. 過度封裝導致除錯困境

JSF 將一切組件化、模型化，類似 Swing 架構。但 HTTP 無狀態本質導致組件樹必須存放伺服器端，開發者無法像 CS 程式便利檢視組件狀態。封裝過深時，遇到問題極難追蹤，除錯成本極高。

2. 自訂組件開發門檻極高

JSF 自訂組件複雜度遠超 JSP Tag Library，修改既有組件行為需深度理解組件生命週期、渲染器、事件處理等核心機制，非資深開發者難以駕馭。

RichFaces 實戰效能陷阱

專案中千行表格頁面搭配 rich:dropdownMenu 導致回應極慢。Root Cause：RichFaces 大量使用 div 產生巢狀 DOM 結構，瀏覽器渲染效能急劇下降。改用原生 html:table 即解決，揭示組件庫效能風險。

Seam In Action 書中總結的 JSF 缺點

1. 初始請求處理過度簡化：缺乏 Struts 類 Controller 機制，首次請求無法執行預處理邏輯
2. 全 POST 請求模式：瀏覽器重整會提示重新提交，使用者體驗差
3. 導航機制單薄：僅支援簡單頁面跳轉
4. 生命週期過度複雜：六大階段執行順序、條件複雜，易產生難以預期的行為

Seam 雖提供解決方案但引入更高複雜度

• EAR 專案結構產生 4 子專案 (war/ear/ejb/test)，小團隊 (3-5 人) 維護負擔過重
• Eclipse workspace 切換導致 EJB 專案編譯錯誤，需關閉重開專案修復，工具穩定性堪慮
• 整合 JSF、EJB3、JPA、jBPM、iText 等過多框架，學習曲線極陡峭

Struts2 對比優勢

結語

「JSF 看起來很美，用起來不爽。」—— 技術選型應以團隊實力、專案規模、維護成本為核心考量，而非追求技術先進性。對中小團隊，Struts2 (或現代 Spring MVC) 仍是務實之選。

系列文章回顧：環境建置 | 核心概念 | 第一個範例 | 第二個範例 | 完結篇