深入解析 Struts 2 框架架構與三種數據傳輸方式

為什麼需要使用框架？

在現代 Web 開發中，框架扮演著至關重要的角色。Struts 2 作為一個成熟的 MVC 框架，幫助開發者自動完成了數據類型轉換、數據驗證、國際化等繁瑣任務。這類似於 Spring 中廣泛使用的 Template 模式，讓開發流程更加自動化、智能化。使用框架的核心優勢在於避免「重複造輪子」，將精力集中在業務邏輯而非基礎設施代碼上。

此外，框架提供了一套成熟的架構規範。開發者只需將業務代碼融入既定流程，即可享受框架帶來的諸多便利。雖然有時可以違背框架規範，但框架通常以難以拒絕的方式提供架構，這讓團隊能以較低成本繼承優秀的架構設計。

從招聘角度看，採用主流框架也更容易找到熟手。自研框架雖然在早期專案中常見，但隨著專案增長，新成員學習成本高、文檔缺失、Bug 難修復，長遠來看維護成本極高。開源框架擁有社區支持，Bug 修復迅速，而內部框架一旦核心開發者離職，幾乎無人維護。

當然，框架並非銀彈。採用不成熟框架有風險，保守專案仍以穩健為主。另外使用小眾框架時需注意 License 協議，避免法律糾紛。

Struts 2 的核心架構

從高層抽象看，Struts 2 仍遵循經典的 MVC 模式。以 HelloWorld 為例：控制器是 FilterDispatcher（在 web.xml 中聲明），模型是 NewsAction，視圖是 news.jsp。模型概念在 Struts 2 中涵蓋了從前端傳入的業務數據與業務邏輯實現。

深入底層，Struts 2 的執行流程如下：

1. 客戶端發送請求，容器封裝為 HttpServletRequest。
2. FilterDispatcher 攔截請求，委派 ActionMapper 確定調用哪個 Action。
3. 根據映射結果，ActionProxy 在 struts.xml 中定位 Action。
4. ActionProxy 創建 ActionInvocation，開始對攔截器和 Action 進行鏈式調用。
5. 各攔截器執行各自任務（如參數填充、驗證等）。
6. 真正調用 Action，獲得結果路徑。
7. Result 對象將結果數據寫入輸出流。
8. 容器發送 HTTP 響應給客戶端。

核心對象是 ActionInvocation（流程總調度）、Interceptor（攔截器）和 ActionContext（上下文）。ActionContext 以 ThreadLocal 形式保存每個請求線程的 ValueStack，使得 Action 和 Result 都能訪問共享數據。

學習 Struts 2 的關鍵在於：讓攔截器與 Action 協作完成任務；將前台數據封裝到 Action；Result 通過 ValueStack 從 Action 獲取輸出數據。

Struts 2 與 Struts 1 的核心差異

1. ActionForm 消失，Action 變身 POJO

Struts 2 摒棄了 ActionForm，前端數據直接封裝到任意 POJO 中。這個 POJO 是 Action 的成員變量。Struts 1 中所有請求共享單個 Action 實例無法這樣做，而 Struts 2 為每個請求創建新 Action 實例，因此線程安全。雖然 Action 同時持有數據和邏輯看似違反單一職責，但實際上極大簡化了開發：拿到數據即可直接調用 Service 層。

2. 前端控制器從 Servlet 變為 Filter

Struts 1 和 Spring MVC 使用 Servlet 作為入口，Struts 2 基於 WebWork 核心，採用 Servlet Filter。這降低了應用與 J2EE API 的耦合：任何 POJO 可作為表單數據載體，任何類無需實現特定接口即可充當 Action。這種非侵入式設計思想與 Spring 的 Aware 接口體系異曲同工，降低了框架侵入性。

3. OGNL 作為粘合劑

OGNL（對象圖導航語言）深度融入 Struts 2。它使訪問 ValueStack 中 Action 屬性如同訪問 ValueStack 自身屬性一樣便利。無論是前台標籤傳值到 Action，還是 Result 從 Action 取值，大量依賴 OGNL。雖然 OGNL 大量使用反射可能影響性能，但換來了靈活、低耦合的架構。

4. 強大的攔截器機制

Struts 2 內建大量攔截器，實現了代碼復用，自動化了數據轉換、驗證等雜務，達到高度關注點分離。這是 AOP 思想在框架中的典型應用。

Struts 2 三種數據傳輸方式實戰

以登錄場景為例，頁面包含用戶名、密碼、記住我三個字段。以下是三種封裝策略：

方式一：JavaBean 屬性直接映射

在 Action 中定義 username、password 等屬性及其 Getter/Setter。表單字段名直接對應屬性名。簡單直觀，但驗證時可能仍需手動組裝 DTO 傳給 Service 層。

方式二：JavaBean 對象封裝

定義 LoginRequest 類承載所有字段，Action 持有 LoginRequest request 屬性。表單字段名需加前綴如 name="request.username"，OGNL 會自動實例化 request 並填充屬性。優點是可直接將 request 傳給 Service，缺點是頁面參數名層級加深。

方式三：ModelDriven 接口實現

Action 實現 ModelDriven<LoginRequest>，並初始化 LoginRequest 實例。表單字段名無需前綴，直接用 username、password。ModelDriven 將模型對象放入 ValueStack 根節點，OGNL 可直接訪問其屬性。代價是需實現額外接口。

三種方式各有優劣，選型取決於項目具體需求：簡單場景用屬性映射，中型表單用 JavaBean 封裝，追求頁面簡潔且模型固定時用 ModelDriven。