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

1.自治視圖

說到自治視圖，可能很多人會感到模式，但是我想很多人（尤其是.NET開發(fā)人員）可能經(jīng)常在采用這種模式來設(shè)計我們的應(yīng)用。Windows Forms和ASP.NET Web Forms雖然分別屬于GUI和Web開發(fā)框架，但是它們都采用了事件驅(qū)動的開發(fā)方式。所有與UI相關(guān)的邏輯都可以定義在針對視圖（Windows Form或者Web Form）的后臺代碼（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邏輯次之，界面邏輯較差。業(yè)務(wù)邏輯具有最強的穩(wěn)定性，UI對業(yè)務(wù)邏輯處理次之，而可視化界面度業(yè)務(wù)邏輯的呈現(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)注點分離（SoC， Seperation of Concerns）的方針將可視化界面呈現(xiàn)、UI處理邏輯和業(yè)務(wù)邏輯三者分離出來，并且采用采用合理的交互方式將它們之間的影響降到最低。由于將三者“分而治之”，自然也使UI邏輯和業(yè)務(wù)邏輯編程的容易被測試的組件，使測試驅(qū)動設(shè)計與開發(fā)變成了可能。這里用于進行關(guān)注點分離的模式就是MVC。

2.MVC模式

MVC的創(chuàng)建者是Trygve M. H. Reenskau，他是挪威的計算機專家，同時也是奧斯陸大學的名譽教授。MVC是他在1979年訪問施樂帕克研究中心（Xerox PARC，Xerox Palo Alto Research Center）期間是提出一種主要針對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三部分，三者各自具有的基本職責或者功能范圍如下：

• Model：是對應(yīng)用狀態(tài)和業(yè)務(wù)功能的封裝，可以看成是同時包含數(shù)據(jù)和行為的領(lǐng)域模型（Domain Model）。Model接受Controller的請求執(zhí)行相應(yīng)的業(yè)務(wù)功能，并在狀態(tài)改變的時候通知View。
• View：實現(xiàn)可視化界面的呈現(xiàn)，捕捉最終用戶的交互操作（比如鼠標和鍵盤操作）。
• Controller：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)。

下圖揭示了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)的事件來處理用戶的交互操作。

3.多層架構(gòu)中的MVC

我看到很多人將MVC和所謂的“三層架構(gòu)”進行比較，其實兩者并沒有什么可比性，MVC更不是分別對應(yīng)著UI、業(yè)務(wù)邏輯和數(shù)據(jù)存取三個層次。不過兩者也不能說完全沒有關(guān)系，我們現(xiàn)在就來討論這個問題。

Trygve M. H. Reenskau當時提出MVC的時候?qū)嶋H上將其作為構(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)用的代理。

博客來自：Artech的《 MVC、MVP以及Model2[上篇]?》

轉(zhuǎn)載于:https://www.cnblogs.com/SanMaoSpace/p/3416135.html

總結(jié)

以上是生活随笔為你收集整理的[转载]MVC、MVP以及Model2(上)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。