前言
儘管MVC早已不是什麼新鮮話題了，但是從近些年一些優秀MVC框架的設計上，我們還是會發現MVC在架構設計上的一些新亮點。本文將對傳統MVC架構中的一些弊病進行解讀，瞭解一些優秀MVC框架是如何化解這些問題的，揭示其中所折射出的設計思想與設計理念。
MVC回顧
作為一種經典到不能再經典的架構模式，MVC的成功有其必然的道理，這個道理不同的人會有不同的解讀，筆者最認同的一種觀點是：通過把職責、性質相近的成分歸結在一起，不相近的進行隔離，MVC將系統分解為模型、視圖、控制器三部分，每一部分都相對獨立，職責單一，在實現過程中可以專注於自身的核心邏輯。MVC是對系統複雜性的一種合理的梳理與切分，它的思想實質就是“關注點分離”。至於MVC三元素的職責劃分與相互關係，這裡不再贅述，下圖給出了非常細緻的說明。
圖1：MVC組件的功能和關係
View與Controller的解耦：mediator+二次事件委派
筆者早年開發基於swing的GUI應用時,在架構MVC的實踐過程中深刻體會到了view與controller之間的緊密耦合問題。在很多事件驅動的GUI框架裡，如swing，用戶對view的任何操作都會觸發一個事件，然後在listener的響應方法裡進行處理。如果讓view自己註冊成為事件的listener,則必須要在view中加入對controller的引用，這不是MVC希望看到的，因為這樣view和controller就形成了緊密的耦合關係。若將controller註冊為listener，則事件響應將由controller承擔，這又會導致controller處理其不該涉及的展現邏輯,造成view和controller難以解耦的原因在於：多數的用戶請求都包含一定成分的展現邏輯和一定成分的業務邏輯，兩種邏輯揉合在一個請求裡，在處理的時候，view與controller很難合理地分工。解決這一問題的關鍵是要在view與controller之間建立一種可以將展現邏輯與業務邏輯進行有效分割的機制，在這方面，PureMVC的設計非常值得參考，它通過引入mediator+二次事件委派機制很好的解決了view與controller之間的緊耦合問題。
PureMVC
PureMVC是一個輕量級框架，用於基於經典的“ 模型-視圖-控制器”設計元模式創建應用程序。它通過使用Multiton Core actor（而不是標準版中使用的Singleton）來支持模塊化編程。
- API文件
- 單元測試
- 討論區
- 舊版實施
Maven安裝
<code>< 依賴項 >
< 依存關係 >
< groupId > org.puremvc groupId >
< artifactId > puremvc-multicore artifactId >
< 版本 > 2.2 版本 >
依賴 >
依賴 >/<code>
演示版
- 員工管理微服務
- Employee Admin Android應用
實用工具
- 管子
平臺/技術
- 爪哇
- 安卓系統
狀態
生產版-2.2版
執照
- 適用於Java的PureMVC MultiCore框架-版權所有©2019 Saad Shams
- PureMVC-版權所有©2019 Futurescale，Inc.
- 版權所有。
- 如果滿足以下條件，則允許以源代碼和二進制形式進行重新分發和使用，無論是否經過修改，都可以：重新分發源代碼必須保留上述版權聲明，此條件列表和以下免責聲明。二進制形式的重新分發必須在分發隨附的文檔和/或其他材料中複製以上版權聲明，此條件列表以及以下免責聲明。未經事先特別書面許可，不得使用Futurescale，Inc.，PureMVC.org的名稱或其貢獻者的名稱來認可或促銷從該軟件衍生的產品。
版權持有者和貢獻者按“原樣”提供此軟件，不提供任何明示或暗示的擔保，包括但不限於針對特定目的的適銷性和適用性的暗示擔保。在任何情況下，版權持有人或貢獻者均不對任何直接，間接，偶發，特殊，特殊或後果性的損害（包括但不限於，替代商品或服務的購買，使用，數據，或業務中斷），無論基於合同，嚴格責任或侵權行為（包括疏忽或其他方式），無論是否出於任何責任，都應通過使用本軟件的任何方式（即使已事先告知）進行了賠償。
Mediator是一種設計模式，這種模式在組件化的圖形界面框架中似乎有著普遍的應用場景，即使是在四人幫的《設計模式》一書中，也使用了一個圖形界面程序的示例來講解mediator。mediator的設計用意在於通過一個媒介對象，完成一組對象的交互，避免對象間相互引用，產生複雜的依賴關係。mediator應用於圖形界面程序時，往往作為一組關係緊密的圖形組件的交互媒介，完成組件間的協調工作(比如點選某一按鈕，其他組件將不可用)。在PureMVC中，mediator被廣泛應用，其定位也發生了微妙的變化，它不再只是圖形組件間的媒介，同時也成為了圖形組件與command之間的媒介，這使得它不再是可選的，而是成為了架構中的必需設施。對應到傳統MVC架構中，mediator就是view與controller之間的媒介（當然，也依然是view之間的媒介），所有從view發出的用戶請求都經過了mediator再傳遞給controller，它的出現在一定程度上緩解了view與controller的緊密耦合問題。
當view、mediator和controller三者被定義出來，並進行了清晰的職責劃分後，剩下的問題就是如何將它們串聯起來，以完成一個用戶請求了，在這方面，事件機制起到了至關重要的作用。事件機制可以讓當前對象專注於處理其職責範圍內的事務，而不必關心超出部分由誰來處理以及怎樣處理，當前對象只需要廣播一個事件，就會有對此事件感興趣的其他對象出來接手下一步的工作，當前對象與接手對象之間不存在直接依賴，甚至感知不到彼此的存在，這是事件機制被普遍認為是一種松耦合機制的重要原因。講到這裡插一句題外話，在領域驅動設計（Domain-Driven Design）裡，著名的Domain Event模式也是有賴於事件機制的這一特性被創造出來的，其用意正是為了保證領域模型的純淨，避免領域模型對repository和service的直接依賴。回到PureMVC, 我們來看在處理用戶請求的過程中，事件機制是如何串聯view、mediator和controller的。在PureMVC裡，當一個用戶請求下達時，圖形組件先在自身的事件響應方法中實現與自身相關的展現邏輯，然後收集數據，將數據置入一個新的event中，將其廣播出去，這是第一次事件委派。這個event會被一個mediator監聽到，如果處理該請求需要其他圖形組件的協助，mediator會協調它們處理應由它們承擔的展現邏輯，然後mediator再次發送一個event(這次的event在PureMVC裡稱之為notification)，這個event會促使某個command執行，完成業務邏輯的計算，這是第二次事件委派。在兩次事件委派中，第一次事件委派讓當事圖形組件完成“處理其職責範圍內的展現邏輯”後，得以輕鬆“脫身”，免於被“協調其他圖件處理剩餘展現邏輯”和“選擇並委派業務對象處理業務邏輯”所拖累。而“協調其他圖形組件處理剩餘展現邏輯”顯然是mediator的職責，於是第一次廣播的事件被委派給了mediator. mediator在完成圖形組件的協調工作後，並不會插手“選擇並委派業務對象處理業務邏輯”的工作，這不是它的職責，因此，第二次事件委派發生了，一個新的event由mediator廣播出去，後被某個command響應到，由command完成了最後的工作——“選擇並委派業務對象處理業務邏輯”。
圖2：mediator+二次事件委派機制
總結起來，PureMVC是通過在view與controller之間引入mediator，讓view與controller變成間接依賴，用戶請求從view到mediator，再從mediator到controller均以事件方式委派，mediator+二次事件委派的組合可以說是一種“強力”的解耦機制，它實現了view與controller之間的完全解耦。
從Controller到Command，自然粒度的迴歸
目前，很多平臺的主流MVC框架在設計上都引入了command模式，command模式的引入改變了傳統ＭＶＣ框架的結構，受衝擊最大的就是controller。在過去傳統的MVC架構裡，一個controller可能有多個方法，每個方法往往對應一個user action,因此，一個 controller往往對應多個user action，而在基於command的MVC架構裡，一個command往往只對應一個user action。傳統MVC架構裡將一個user action委派到某個controller的某個方法的過程，在基於command的MVC架構裡變成了將useraction與command一一綁定的過程。如果說傳統controller的管理方式是在user action與model之間建立“集中式”的映射，那麼基於command的管理方式就是在user action與model之間建立“點對點式”的直連映射。
圖3：從基於Controller到基於Command的架構演進
主流MVC框架向command轉型是有原因的，除了command自身的優勢之外，一個非常重要的原因就是：由於缺少合理的組織依據，controller的粒度很難拿捏。controller不同於view與model，view與model都有各自天然的粒度組織依據，view的組織粒度直接承襲用戶界面設計，model的組織粒度則是依據某種分析設計思想（如OOA/D）進行領域建模的結果，controller需要同時協調view與model，但是view與model的組織結構和粒度都是不對等的，這就使得controller面臨一個“在多大視圖範圍內溝通與協調多少領域對象”的問題，由於找不出合理的組織依據，設計者在設計controller時往往感到無所適從。相比之下，command則完全沒有controller的困惑，因為command有一個天然的組織依據，這就是user action。針對一個user action設計一個command，然後將兩者映射在一起，是一件非常自然而簡單的事情。不過，需要說明的是這並不意味著所有command的粒度是一樣的，因為不同的user action所代表的業務量是不同的，因此也決定了command是有“大”有“小”的。遵循良好的設計原則，對某些較“大”的command進行分解，從中抽離出一些可複用的部分封裝成一些較“小”的command是值得推薦的。很多MVC框架就定義了一些相關的接口和抽象類用於支持基於組合模式的命令拼裝。
不管是基於controller還是基於command，MVC架構中界定的“協調view與model交互”的控制器職責是不會變的，都需要相應的組件和機制去承載與實現。在基於command的架構裡，command承擔了過去controller的部分職責，從某種意義上說 command是一種細粒度的controller，但是command的特性是偏“被動”的。一方面，它對於view和model的控制力比controller弱化了很多， 比如，一般情況下command是不會直接操縱view的。另一方面，它不知道自己與什麼樣的user action映射在了一起，也不知道自己會在何種情況下被觸發執行。支撐command的運行需要額外的註冊、綁定和觸發機制，是這些機制加上command一起實現了controller的職責。由於現在多數基於command的MVC框架都實現並封裝了這些重要的機制，所以從某種意義上說，是這些框架自身扮演了controller角色。
小結
本文主要分析了過去傳統MVC架構中存在的兩大弊病：view與controller的緊密耦合以及controller粒度難以把控的問題，介紹了一些MVC框架是如何應對這些問題的，這些設計方案所體現出的優秀設計思想是非常值得學習的。
閱讀更多 java程序員工程師 的文章
