傳統MVC模式

傳統MVC模式

對於大部分面向終端使用者的應用來說，它們都需要具有一個視覺化的UI介面與使用者進行互動，我們將這個UI稱為檢視（View）。在早期，我們傾向於將所有與UI相關的操作糅合在一起，這些操作包括UI介面的呈現、用於互動操作的捕捉與響應、業務流程的執行以及對資料的存取，我們將這種設計模式稱為自治檢視（Autonomous View，AV）。

自治檢視

說到自治檢視，很多人會感到陌生，但是我們（尤其是.NET開發人員）可能經常在採用這種模式來設計我們的應用。Windows Forms和ASP.NET Web Forms雖然分別屬於GUI和Web開發框架，但是它們都採用了事件驅動的開發方式，所有與UI相關的邏輯都可以定義在針對檢視（Windows Forms或者Web Forms）的後臺程式碼（Code Behind）中，並最終註冊到檢視本身或者檢視元素（控制元件）的相應事件上。

一個典型的人機互動應用具有三個主要的關注點，即資料在視覺化介面上的呈現、UI處理邏輯（用於處理使用者互動式操作的邏輯）和業務邏輯。自治檢視模式將三者混合在一起，勢必會帶來如下一些問題：

業務邏輯是與UI無關的，應該最大限度地被重用。由於業務邏輯定義在自治檢視中，相當於完全與檢視本身繫結在一起，如果我們能夠將UI的行為抽象出來，基於抽象化UI的處理邏輯也是可以被共享的。但是定義在自治檢視中的UI處理邏輯完全喪失了重用的可能。

業務邏輯具有最強的穩定性，UI處理邏輯次之，而視覺化介面上的呈現最差（比如我們經常會為了更好地呈現效果來調整HTML）。如果將具有不同穩定性的元素融為一體，那麼具有最差穩定性的元素決定了整體的穩定性，這是“短板理論”在軟體設計中的體現。

任何涉及UI的元件都不易測試。UI是呈現給人看的，並且用於與人進行互動，用機器來模擬活生生的人來對元件實施自動化測試不是一件容易的事，自治檢視嚴重損害了元件的可測試性。

為了解決自治檢視導致的這些問題，我們需要採用關注點分離（Seperation of Concerns，SoC）的方針將視覺化介面呈現、UI處理邏輯和業務邏輯三者分離出來，並且採用合理的互動方式將它們之間的依賴降到最低。將三者“分而治之”，自然也使UI邏輯和業務邏輯變得更容易測試，測試驅動設計與開發變成了可能。這裡用於進行關注點分離的模式就是MVC。

什麼是MVC模式

MVC的建立者是Trygve M. H. Reenskau，他是挪威的計算機專家，同時也是奧斯陸大學的名譽教授。MVC是他在1979年訪問施樂帕克研究中心（Xerox Palo Alto Research Center，Xerox PARC）期間提出一種主要針對GUI應用的軟體架構模式。MVC最初用於SmallTalk，Trygve最初對MVC的描述記錄在Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC)這篇論文中，有興趣的讀者可以透過地址 users/smarch/st-docs/mvc.html閱讀這篇論文。

MVC體現了關注點分離這一基本的設計方針，它將構成一個人機互動應用涉及的功能分為Model、Controller和View三部分，它們各自具有相應的職責。

Model是對應用狀態和業務功能的封裝，我們可以將它理解為同時包含資料和行為的領域模型（Domain Model）。Model接受Controller的請求並完成相應的業務處理，在狀態改變的時候向View發出相應的通知。

View實現視覺化介面的呈現並捕捉終端使用者的互動操作（比如滑鼠和鍵盤操作）。

View捕獲到使用者互動操作後會直接轉發給Controller，後者完成相應的UI邏輯。如果需要涉及業務功能的呼叫，Controller會直接呼叫Model。在完成UI處理之後，Controller會根據需要控制原View或者建立新的View對使用者互動操作予以響應。

圖1-1揭示了MVC模式下Model、View和Controller之間的互動。對於傳統的MVC模式，很多人認為Controller僅僅是View和Model之間的中介，實則不然，View和Model存在直接的聯絡。View可以直接呼叫Model查詢其狀態資訊。當Model狀態發生改變的時候，它也可以直接通知View。比如在一個提供股票實時價位的應用中，維護股價資訊的Model在股價變化的情況下可以直接通知相關的View改變其顯示資訊。

從訊息交換模式的角度來講，Model針對View的狀態通知和View針對Controller的使用者互動通知都是單向的，我們推薦採用事件機制來實現這兩種型別的通知。從設計模式的角度來講就是採用觀察者（Observer）模式透過註冊/訂閱的方式來實現它們，即View作為Model的觀察者透過註冊相應的事件來檢測狀態的改變，而Controller作為View的觀察者透過註冊相應的事件來處理使用者的互動操作。

我看到很多人將MVC和所謂的“三層架構”進行比較，其實兩者並沒有什麼可比性，MVC更不是分別對應著UI、業務邏輯和資料存取三個層次，不過兩者也不能說完全沒有關係。Trygve M. H. Reenskau當時提出MVC的時候是將其作為構建整個GUI應用的架構模式，這種情況下的Model實際上維護著整個應用的狀態並實現了所有的業務邏輯，所以它更多地體現為一個領域模型。而對於多層架構來說（比如我們經常提及的三層架構），MVC是被當成UI呈現層（Presentation Layer）的設計模式，而Model則更多地體現為訪問業務層的入口（Gateway）。如果採用面向服務的設計，業務功能被定義成相應服務並透過介面（契約）的形式暴露出來，這裡的Model還可以表示成進行服務呼叫的代理。

本文節選自《ASP.NET MVC 4 框架揭秘》

蔣金楠 著

電子工業出版社出版