傳統(tǒng)MVC模式

傳統(tǒng)MVC模式

對于大部分面向最終用戶的應(yīng)用來說，它們都需要具有一個可視化的UI界面與用戶進行交互，我們將這個UI稱為視圖（View）。在早期，我們傾向于將所有與UI相關(guān)的操作糅合在一起，這些操作包括UI界面的呈現(xiàn)、用于交互操作的捕捉與響應(yīng)、業(yè)務(wù)流程的執(zhí)行以及對數(shù)據(jù)的存取，我們將這種設(shè)計模式稱為自治視圖（Autonomous View，AV）。

自治視圖

說到自治視圖，很多人會感到陌生，但是我們（尤其是.NET開發(fā)人員）可能經(jīng)常在采用這種模式來設(shè)計我們的應(yīng)用。Windows Forms和ASP.NET Web Forms雖然分別屬于GUI和Web開發(fā)框架，但是它們都采用了事件驅(qū)動的開發(fā)方式，所有與UI相關(guān)的邏輯都可以定義在針對視圖（Windows Forms或者Web Forms）的后臺代碼（Code Behind）中，并最終注冊到視圖本身或者視圖元素（控件）的相應(yīng)事件上。

一個典型的人機交互應(yīng)用具有三個主要的關(guān)注點，即數(shù)據(jù)在可視化界面上的呈現(xiàn)、UI處理邏輯（用于處理用戶交互式操作的邏輯）和業(yè)務(wù)邏輯。自治視圖模式將三者混合在一起，勢必會帶來如下一些問題：

業(yè)務(wù)邏輯是與UI無關(guān)的，應(yīng)該最大限度地被重用。由于業(yè)務(wù)邏輯定義在自治視圖中，相當于完全與視圖本身綁定在一起，如果我們能夠?qū)I的行為抽象出來，基于抽象化UI的處理邏輯也是可以被共享的。但是定義在自治視圖中的UI處理邏輯完全喪失了重用的可能。

業(yè)務(wù)邏輯具有最強的穩(wěn)定性，UI處理邏輯次之，而可視化界面上的呈現(xiàn)最差（比如我們經(jīng)常會為了更好地呈現(xiàn)效果來調(diào)整HTML）。如果將具有不同穩(wěn)定性的元素融為一體，那么具有最差穩(wěn)定性的元素決定了整體的穩(wěn)定性，這是“短板理論”在軟件設(shè)計中的體現(xiàn)。

任何涉及UI的組件都不易測試。UI是呈現(xiàn)給人看的，并且用于與人進行交互，用機器來模擬活生生的人來對組件實施自動化測試不是一件容易的事，自治視圖嚴重損害了組件的可測試性。

為了解決自治視圖導(dǎo)致的這些問題，我們需要采用關(guān)注點分離（Seperation of Concerns，SoC）的方針將可視化界面呈現(xiàn)、UI處理邏輯和業(yè)務(wù)邏輯三者分離出來，并且采用合理的交互方式將它們之間的依賴降到最低。將三者“分而治之”，自然也使UI邏輯和業(yè)務(wù)邏輯變得更容易測試，測試驅(qū)動設(shè)計與開發(fā)變成了可能。這里用于進行關(guān)注點分離的模式就是MVC。

什么是MVC模式

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

MVC體現(xiàn)了關(guān)注點分離這一基本的設(shè)計方針，它將構(gòu)成一個人機交互應(yīng)用涉及的功能分為Model、Controller和View三部分，它們各自具有相應(yīng)的職責。

Model是對應(yīng)用狀態(tài)和業(yè)務(wù)功能的封裝，我們可以將它理解為同時包含數(shù)據(jù)和行為的領(lǐng)域模型（Domain Model）。Model接受Controller的請求并完成相應(yīng)的業(yè)務(wù)處理，在狀態(tài)改變的時候向View發(fā)出相應(yīng)的通知。

View實現(xiàn)可視化界面的呈現(xiàn)并捕捉最終用戶的交互操作（比如鼠標和鍵盤操作）。

View捕獲到用戶交互操作后會直接轉(zhuǎn)發(fā)給Controller，后者完成相應(yīng)的UI邏輯。如果需要涉及業(yè)務(wù)功能的調(diào)用，Controller會直接調(diào)用Model。在完成UI處理之后，Controller會根據(jù)需要控制原View或者創(chuàng)建新的View對用戶交互操作予以響應(yīng)。

圖1-1揭示了MVC模式下Model、View和Controller之間的交互。對于傳統(tǒng)的MVC模式，很多人認為Controller僅僅是View和Model之間的中介，實則不然，View和Model存在直接的聯(lián)系。View可以直接調(diào)用Model查詢其狀態(tài)信息。當Model狀態(tài)發(fā)生改變的時候，它也可以直接通知View。比如在一個提供股票實時價位的應(yīng)用中，維護股價信息的Model在股價變化的情況下可以直接通知相關(guān)的View改變其顯示信息。

從消息交換模式的角度來講，Model針對View的狀態(tài)通知和View針對Controller的用戶交互通知都是單向的，我們推薦采用事件機制來實現(xiàn)這兩種類型的通知。從設(shè)計模式的角度來講就是采用觀察者（Observer）模式通過注冊/訂閱的方式來實現(xiàn)它們，即View作為Model的觀察者通過注冊相應(yīng)的事件來檢測狀態(tài)的改變，而Controller作為View的觀察者通過注冊相應(yīng)的事件來處理用戶的交互操作。

我看到很多人將MVC和所謂的“三層架構(gòu)”進行比較，其實兩者并沒有什么可比性，MVC更不是分別對應(yīng)著UI、業(yè)務(wù)邏輯和數(shù)據(jù)存取三個層次，不過兩者也不能說完全沒有關(guān)系。Trygve M. H. Reenskau當時提出MVC的時候是將其作為構(gòu)建整個GUI應(yīng)用的架構(gòu)模式，這種情況下的Model實際上維護著整個應(yīng)用的狀態(tài)并實現(xiàn)了所有的業(yè)務(wù)邏輯，所以它更多地體現(xiàn)為一個領(lǐng)域模型。而對于多層架構(gòu)來說（比如我們經(jīng)常提及的三層架構(gòu)），MVC是被當成UI呈現(xiàn)層（Presentation Layer）的設(shè)計模式，而Model則更多地體現(xiàn)為訪問業(yè)務(wù)層的入口（Gateway）。如果采用面向服務(wù)的設(shè)計，業(yè)務(wù)功能被定義成相應(yīng)服務(wù)并通過接口（契約）的形式暴露出來，這里的Model還可以表示成進行服務(wù)調(diào)用的代理。

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

蔣金楠 著

電子工業(yè)出版社出版