從 MVC 框架演進看架構設計精髓：Mediator 模式與 Command 模式的解耦之道

MVC 雖是經典模式，但優秀框架（PureMVC、Spring MVC、Struts2）在落地時對傳統 MVC 痛點進行了深度重構。本文剖析 View-Controller 緊耦合與 Controller 粒度難控兩大核心難題，揭示 Mediator+雙重事件委派、Command 模式如何實現架構級解耦。

一、MVC 回顧：關注點分離的本質

MVC 將系統分解為 Model（業務數據與規則）、View（展現邏輯）、Controller（協調與分派），實現「關注點分離」。但傳統實現中，View 與 Controller 常陷入緊耦合，Controller 粒度把控困難。

二、痛點一：View 與 Controller 緊耦合

2.1 事件驅動場景下的困境

在 Swing、JavaFX 等事件驅動 GUI 框架中，用戶操作觸發事件：

• View 註冊 Listener → 需持有 Controller 引用 → View 依賴 Controller
• Controller 註冊 Listener → Controller 處理展現邏輯 → 職責越界

核心矛盾：單一用戶請求同時包含展現邏輯與業務邏輯，傳統 MVC 難以在處理鏈中乾淨分離。

2.2 PureMVC 解法：Mediator + 雙重事件委派

1. 第一次委派（View → Mediator）：組件處理自身展現邏輯 → 封裝數據廣播 Event → Mediator 監聽協調其他組件完成剩餘展現邏輯。
2. 第二次委派（Mediator → Command）：Mediator 廣播 Notification → Command 響應執行業務邏輯（選擇並委派 Service/DAO）。

2.3 關鍵設計決策

這實現了 View 與 Controller（Command）的完全解耦：View 不知 Command 存在，Command 不知 View 存在，Mediator 作為純粹中介者串聯雙方。

三、痛點二：Controller 粒度難以把控

3.1 傳統 Controller 的困境

• 一個 Controller 含多個 Action 方法，對應多個用戶請求
• View 粒度源自 UI 設計，Model 粒度源自領域建模，兩者不對等
• Controller 需同時協調 View 與 Model，缺乏天然組織依據，導致「大而全」或「碎片化」

3.2 Command 模式：自然粒度的回歸

• 天然組織依據：User Action → 一個 Action 對應一個 Command 類
• 點對點映射：Action ↔ Command 直連，替代 Controller 的集中式映射
• 粒度自適應：簡單 Action 對應輕量 Command，複雜 Action 通過組合模式拆分為粗粒度 Command + 多個細粒度可復用 SubCommand

3.3 Command 的特性與框架角色

• 被動特性：Command 不知自己映射哪個 Action、何時被觸發、不直接操作 View
• 框架即 Controller：註冊、綁定、觸發機制由框架封裝，框架本身扮演了宏觀 Controller 角色
• 組合支撐：優秀框架提供 CompositeCommand、CommandChain 支撐命令組裝與管道處理

四、架構設計啟示

1. 引入中介者打破雙向依賴：當兩個組件難以直接解耦時，引入第三方中介者，雙向依賴轉為單向依賴中介者。
2. 事件機制實現時空解耦：發送者無需知道接收者誰、何時處理，只關心「發什麼事件」。
3. 職責劃分遵循「單一職責+高內聚」：展現邏輯留在 View/Mediator，業務邏輯進 Command/Service，數據訪問進 Repository。
4. 粒度源自業務語義而非技術結構：Command 以 User Action 為粒度鍵，天然契合業務變化。
5. 框架吸收基礎設施複雜度：註冊/發現/生命週期/異常處理下沉框架，業務代碼保持純淨。

五、現代框架映射

理解 MVC 演進史，本質上是理解如何在復雜系統中劃清邊界、建立契約、最小化知識依賴。Mediator 與 Command 不僅是模式，更是架構師手中的手術刀，精準切開耦合腫瘤，重塑健康的系統解剖結構。