MVC是Trygve M. H. Reenskau在1979年訪問施樂帕克研究中心（Xerox PARC）期間是提出一種主要針對GUI應用的軟件架構模式。MVC體現了關注點分離這一基本的設計方針，它將構成一個人機交互應用涉及到的功能分為Model、Controller和View三部分。本篇文章（上、下篇）為你詳細介紹MVC模式和它兩個常用的變體MVP和Model2。

對于大部分面向最終用戶的應用來說，它們都需要具有一個可視化的UI與用戶進行交互，我們將這個UI稱為視圖（View）。在早期，我們傾向于將所有與視圖相關的邏輯糅合在一起，這些邏輯包括數據的呈現、用戶操作的捕捉與相應以及和針對數據存儲（比如數據庫）的操作。我們將這種設計模式稱為自治視圖（AV，Autonomous View）。

目錄
一、自治視圖
二、MVC模式
三、多層架構中的MVC

一、自治視圖

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

一個典型的人機交互應用具有三個主要的關注點，即數據在可視化界面上的呈現、UI處理邏輯（用于處理用戶交互式操作的邏輯）和業務邏輯。對于自治視圖模式來說，它實際上這三種混合在一起，勢必會帶來如下一些問題：

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

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

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

為了解決自治視圖導致的這些問題，我們需要采用采用關注點分離（SoC， Seperation of Concerns）的方針將可視化界面呈現、UI處理邏輯和業務邏輯三者分離出來，并且采用采用合理的交互方式將它們之間的影響降到最低。由于將三者“分而治之”，自然也使UI邏輯和業務邏輯編程的容易被測試的組件，使測試驅動設計與開發變成了可能。這里用于進行關注點分離的模式就是MVC。

二、MVC模式

MVC的創建者是Trygve M. H. Reenskau，他是挪威的計算機專家，同時也是奧斯陸大學的名譽教授。MVC是他在1979年訪問施樂帕克研究中心（Xerox PARC，Xerox Palo Alto Research Center）期間是提出一種主要針對GUI應用的軟件架構模式。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體現了關注點分離這一基本的設計方針，它將構成一個人機交互應用涉及到的功能分為Model、Controller和View三部分，三者各自具有的基本職責或者功能范圍如下：

• Model：是對應用狀態和業務功能的封裝，可以看成是同時包含數據和行為的領域模型（Domain Model）。Model接受Controller的請求執行相應的業務功能，并在狀態改變的時候通知View。
• View：實現可視化界面的呈現，捕捉最終用戶的交互操作（比如鼠標和鍵盤操作）。
• Controller：View捕獲到用戶交互操作后會直接轉發給Controller，后者完成相應的UI邏輯。如果需要涉及業務功能的調用，Controller會直接調用Model。在完成UI處理之后，Controller會根據需要控制原View或者創建新的View對用戶交互操作予以響應。

下圖揭示了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和所謂的“三層架構”進行比較，其實兩者并沒有什么可比性，MVC更不是分別對應著UI、業務邏輯和數據存取三個層次。不過兩者也不能說完全沒有關系，我們現在就來討論這個問題。

Trygve M. H. Reenskau當時提出MVC的時候實際上將其作為構建整個GUI應用的架構模式，而Model維護著整個應用的狀態并實現了所有的業務邏輯，它更多地體現為一個領域模型。而對于多層架構來說（比如我們經常提及的三層架構），MVC是被當成是UI呈現層（Presentation Layer）的設計模式，而Model則更多地體現為訪問業務層的入口（Gateway）。如果采用面向服務的設計，將業務功能定義成相應服務并通過接口（契約）的形式暴露出來，這里的Model甚至還可以表示成進行服務調用的代理。

MVC、MVP以及Model2[上篇]
MVC、MVP以及Model2[下篇]