Model-View-Controller（模型-視圖-控制器）
本頁內(nèi)容
上下文
許多計算機系統(tǒng)的用途都是從數(shù)據(jù)存儲檢索數(shù)據(jù)并將其顯示給用戶。在用戶更改數(shù)據(jù)之后，系統(tǒng)再將更新內(nèi)容存儲到數(shù)據(jù)存儲中。因為關(guān)鍵的信息流發(fā)生在數(shù)據(jù)存儲和用戶界面之間，所以您可能傾向于將這兩部分綁在一起，以減少編碼量并提高應(yīng)用程序性能。但是，這種看起來自然而然的方法有一些大問題。一個問題是，用戶界面的更改往往比數(shù)據(jù)存儲系統(tǒng)的更改頻繁得多。將數(shù)據(jù)和用戶界面這兩部分耦合在一起帶來的另一個問題是，業(yè)務(wù)應(yīng)用程序往往會并入遠不止數(shù)據(jù)傳輸功能的其他業(yè)務(wù)邏輯。
問題
如何讓 Web 應(yīng)用程序的用戶界面功能實現(xiàn)模塊化，以便您可以輕松地單獨修改各個部分？
影響因素
下列影響因素作用于此上下文內(nèi)的系統(tǒng)，在考慮問題的解決方案時必須協(xié)調(diào)這些因素
-
用戶界面邏輯的更改往往比業(yè)務(wù)邏輯頻繁，尤其是在基于 Web 的應(yīng)用程序中。例如，可能添加新的用戶界面頁，或者可能完全打亂現(xiàn)有的頁面布局。畢竟，基于 Web 的瘦客戶端應(yīng)用程序的優(yōu)點之一是可以隨時更改用戶界面，而不必重新分發(fā)應(yīng)用程序。如果將顯示代碼和業(yè)務(wù)邏輯組合一起并放在單個對象中，則每次更改用戶界面時，都必須修改包含業(yè)務(wù)邏輯的對象。這很可能引入錯誤，并需要在對用戶界面進行每個極小更改之后都要重新測試所有業(yè)務(wù)邏輯。
-
在某些情況下，應(yīng)用程序以不同的方式顯示同一數(shù)據(jù)。例如，分析員喜歡用電子表格視圖顯示數(shù)據(jù)，而管理人員喜歡用餅圖顯示相同的數(shù)據(jù)。在一些胖客戶端用戶界面中，常常用多個視圖同時顯示相同數(shù)據(jù)。如果用戶在一個視圖中更改了數(shù)據(jù)，則系統(tǒng)必須自動更新該數(shù)據(jù)的其他所有視圖。
-
設(shè)計令人賞心悅目而有效的 HTML 頁通常要求采用一套與開發(fā)復(fù)雜業(yè)務(wù)邏輯不同的技能。很少有人同時具有這兩種技能。因此，將這兩部分的開發(fā)工作分隔開來是最理想的。
-
用戶界面活動通常由以下兩部分組成：顯示和更新。顯示部分負責(zé)從數(shù)據(jù)源檢索數(shù)據(jù)，并格式化數(shù)據(jù)以便進行顯示。當(dāng)用戶基于該數(shù)據(jù)執(zhí)行操作時，更新部分將控制權(quán)返回給業(yè)務(wù)邏輯，以便更新數(shù)據(jù)。
-
在 Web 應(yīng)用程序中，單個頁面請求將這兩方面的工作組合在一起：與用戶所選鏈接相關(guān)聯(lián)的操作進行的處理，以及目標(biāo)頁面的顯示。在許多情況下，目標(biāo)頁可能不與操作直接相關(guān)。例如，假設(shè)有一個用于顯示項目列表的簡單 Web 應(yīng)用程序。在將項目添加到列表或從列表中刪除項目之后，用戶將返回主列表頁。因此，應(yīng)用程序必須在執(zhí)行兩個有很大差異的命令（添加或刪除）之后顯示相同頁面（列表），而所有這些操作均在同一個 HTTP 請求內(nèi)進行。
-
與業(yè)務(wù)邏輯相比，用戶界面代碼對設(shè)備的依賴性往往更大。如果要將應(yīng)用程序從基于瀏覽器的應(yīng)用程序遷移到個人數(shù)字助理 (PDA) 或支持 Web 的手機上，則必須替換很多用戶界面代碼，而業(yè)務(wù)邏輯可能不受影響。這兩部分的完全分離可以使遷移更快完成，并最大限度地降低將錯誤引入業(yè)務(wù)邏輯的風(fēng)險。
-
通常，為用戶界面創(chuàng)建自動測試比為業(yè)務(wù)邏輯更難、更耗時。因此，減少直接綁到用戶界面中的代碼量可提高應(yīng)用程序的可測試性。
解決方案
Model-View-Controller (MVC) 模式基于用戶輸入將域的建模、顯示和操作分為三個獨立的類 [Burbeck92]：
-
模型。模型用于管理應(yīng)用程序域的行為和數(shù)據(jù)，并響應(yīng)為獲取其狀態(tài)信息（通常來自視圖）而發(fā)出的請求，還會響應(yīng)更改狀態(tài)的指令（通常來自控制器）。
-
視圖。視圖用于管理信息的顯示。
-
控制器。控制器用于解釋用戶的鼠標(biāo)和鍵盤輸入，以通知模型和/或視圖進行相應(yīng)的更改。
圖 1 描述了這三個對象之間的結(jié)構(gòu)關(guān)系。
請務(wù)必注意，視圖和控制器都依賴于模型。但是，模型既不依賴于視圖，也不依賴于控制器。這是分離的主要優(yōu)點之一。這樣的分離允許模型在獨立于可視表示功能的情況下建立和測試。在許多胖客戶端應(yīng)用程序中，視圖與控制器的分離是次要的，實際上，許多用戶界面框架將角色實現(xiàn)為一個對象。另一方面，在 Web 應(yīng)用程序中，視圖（瀏覽器）與控制器（處理 HTTP 請求的服務(wù)器端組件）的分離是很好定義的。
Model-View-Controller 是一個用于將用戶界面邏輯與業(yè)務(wù)邏輯分離開來的基礎(chǔ)設(shè)計模式。遺憾的是，此模式的普及導(dǎo)致了許多錯誤的描述。特別是在不同的上下文中，術(shù)語"控制器"已經(jīng)用于意指不同的事物。幸運的是，Web 應(yīng)用程序的出現(xiàn)已經(jīng)幫助消除了一些不明確性，因為視圖與控制器的分離是如此明顯。
變型
在 Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC) [Burbeck92] 中，Steve Burbeck 描述了 MVC 的兩個變型：被動模型和主動模型。
當(dāng)一個控制器以獨占方式操作模型時，將使用被動模型?？刂破鲗⑿薷哪Ｐ?，然后通知視圖：模型已經(jīng)更改，應(yīng)該進行刷新（見圖 2）。此情況下的模型完全獨立于視圖和控制器，這意味著模型無法報告其狀態(tài)更改。HTTP 協(xié)議是此方案的示例。瀏覽器沒有從服務(wù)器獲取異步更新的簡單方法。瀏覽器顯示視圖并對用戶輸入作出響應(yīng)，但是它不會檢測服務(wù)器上的數(shù)據(jù)更改。僅當(dāng)用戶顯式請求刷新時，才會詢問服務(wù)器是否發(fā)生了更改。
當(dāng)模型更改狀態(tài)而不涉及控制器時，將使用主動模型。當(dāng)其他資源正在更改數(shù)據(jù)并且更改必須反映在視圖中時，可能會發(fā)生這種情況。以股票報價機的顯示為例。您從外部源接收股票數(shù)據(jù)，并希望當(dāng)股票數(shù)據(jù)更改時更新視圖（例如，報價機數(shù)據(jù)區(qū)和警告窗口）。因為只有模型檢測對其內(nèi)部狀態(tài)的更改（在這些更改發(fā)生時），所以模型必須通知視圖刷新顯示。
但是，使用 MVC 模式的一個目的是使模型獨立于視圖。如果模型必須將更改通知視圖，則會重新帶來您希望避免的依賴性。幸運的是，Observer 模式 [Gamma95] 提供了這樣的機制：提醒其他對象注意狀態(tài)的更改，而不會導(dǎo)致對這些對象的依賴性。各個視圖實現(xiàn) Observer 接口，并向模型注冊。模型將跟蹤由訂閱更改的所有觀察器組成的列表。當(dāng)模型發(fā)生改變時，模型將會遍歷所有已注冊的觀察器，并將更改通知它們。此方法通常稱為"發(fā)布-訂閱"。模型從不需要有關(guān)任何視圖的特定信息。實際上，在需要將模型更改通知控制器的情況下（例如，啟用或禁用菜單選項），控制器必須做的全部工作是實現(xiàn) Observer 接口并訂閱模型更改。對于存在許多視圖的情況，定義多個主體是有意義的，其中每個主體都描述了特定類型的模型更改。然后，每個視圖都只能訂閱與視圖有關(guān)的更改類型。
圖 3 顯示了使用 Observer 的主動 MVC 的結(jié)構(gòu)，以及觀察器如何將模型與直接引用視圖隔離開來。
圖 4 說明當(dāng)模型發(fā)生改變時 Observer 如何通知視圖。可惜的是，在統(tǒng)一建模語言 (UML) 序列圖中，沒有好的方法來演示模型與視圖的分離，因為該圖表示的是對象的實例而不是類和接口。
示例
參考Implementing Model-View-Controller in ASP.NET
測試考慮事項
在使用 Model-View-Controller 時，可測試性有了極大提高。當(dāng)組件（尤其是用戶界面組件）相互高度依賴時，測試組件變得很困難。這些類型的組件通常需要復(fù)雜的設(shè)置，只是為了測試簡單的功能。更糟的是，在出現(xiàn)錯誤時，很難確定該問題發(fā)生在哪個特定組件上。這就是為什么將任務(wù)分離開來是重要的體系結(jié)構(gòu)級別動機。MVC 將存儲、顯示和更新數(shù)據(jù)的任務(wù)分隔到三個可以分別進行測試的組件中。
除因互相依賴而產(chǎn)生的問題之外，用戶界面框架本身是很難測試的。測試用戶界面需要冗長乏味的（且易于出錯）手動測試，或需要模擬用戶操作的測試腳本。這些腳本的開發(fā)往往很耗時，而且容易被破壞。MVC 沒有消除對用戶界面測試的需要，但是，通過將模型與顯示邏輯分離，可以允許模型在獨立于顯示的情況下進行測試，并減少了用戶界面的測試步驟數(shù)。
結(jié)果上下文
圍繞 MVC 模式構(gòu)建顯示層具有下列優(yōu)缺點：
優(yōu)點
-
支持多個視圖。因為視圖與模型分離，而且模型與視圖之間沒有直接依賴性，所以用戶界面可以同時顯示同一數(shù)據(jù)的多個視圖。例如，Web 應(yīng)用程序中的多個頁面可以使用同一模型對象。另一個示例是允許用戶對頁面外觀進行更改的 Web 應(yīng)用程序。這些頁面顯示來自共享模型的同一數(shù)據(jù)，但以不同的方式進行顯示。
-
適應(yīng)更改。用戶界面要求的更改往往比業(yè)務(wù)規(guī)則快。用戶可能更喜歡新設(shè)備（如手機或 PDA）采用另一顏色、字體、屏幕布局和支持級別。因為模型不依賴于視圖，所以將新類型的視圖添加到系統(tǒng)中通常不會影響模型。因此，更改的作用范圍僅限于視圖。此模式為其進一步的專門化模式（如 Page Controller 和Front Controller）奠定了基礎(chǔ)。
缺點
-
復(fù)雜性。MVC 模式引入了新的間接級別，因此稍微增加了解決方案的復(fù)雜性。它還增加了用戶界面代碼的事件驅(qū)動特性，調(diào)試用戶界面代碼會變得更加困難。
-
頻繁更新的成本。將模型與視圖分離并不意味著模型的開發(fā)人員可以忽略視圖的特性。例如，如果模型發(fā)生頻繁更改，則它可能向視圖發(fā)出大量更新請求。一些視圖（如圖形顯示）的顯示可能需要一定時間。因此，視圖可能滯后于更新請求。因此，在對模型進行編碼時牢記視圖是很重要的。例如，模型可以將多個更新作為單個通知發(fā)送到視圖。
變體
Document-View 變體可以識別 Model-View-Controller 的所有三個角色，但它把控制器合并到視圖中。文檔對應(yīng)于 MVC 中的模型角色。此變體存在于許多現(xiàn)有 GUI 平臺中。Document-View 的一個極佳示例是 Microsoft Visual C++® 環(huán)境中的 Microsoft® 基礎(chǔ)類庫 (MFC)。使用此變體時，要考慮到視圖與控制器更緊密耦合的影響。
相關(guān)模式
有關(guān)詳細信息，請參閱下列相關(guān)模式：
-
Observer。此模式通常與 MVC 一起提及，因為需要使視圖和關(guān)聯(lián)模型保持同步。
-
Page Controller 和Front Controller 描述 MVC 模式的控制器部分的實現(xiàn)策略。
致謝
Model-View-Controller 最初是 Trygve Reenskaug 在二十世紀(jì)七十年代末為 Smalltalk 平臺開發(fā)的框架 [Fowler03]。您剛才閱讀的版本參考了以下著作：
[Burbeck92] Burbeck, Steve. "Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC)." University of Illinois in Urbana-Champaign (UIUC) Smalltalk Archive. Available at: http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html.
[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
[Gamma95] Gamma, Helm, Johnson, and Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
