通過(guò)采用MVC模式，我們可以將可視化UI元素的呈現(xiàn)、UI處理邏輯和業(yè)務(wù)邏輯分別定義在View、Controller和Model中，但是對(duì)于三者之間的交互，MVC并沒(méi)有進(jìn)行嚴(yán)格的限制。最為典型的就是允許View和Model繞開(kāi)Controller進(jìn)行直接交互，View不僅僅可以通過(guò)調(diào)用Model獲取需要呈現(xiàn)給用戶的數(shù)據(jù)，Model也可以直接通知View讓其感知到狀態(tài)的變化。當(dāng)真正地將MVC應(yīng)用于具體的項(xiàng)目開(kāi)發(fā)中，不論是基于GUI的桌面應(yīng)用還是基于Web UI的Web應(yīng)用，如果不對(duì)Model、View和Controller之間的交互進(jìn)行更為嚴(yán)格的限制，我們編寫(xiě)的程序可以比自治視圖更為難以維護(hù)。

今天我們將MVC視為一種模式（Pattern），但是作為MVC最初提出者的Trygve M. H. Reenskau實(shí)際是將MVC視為一種范例（Paradigm），這可以從它在《Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC)》中對(duì)MVC的描述可以看出來(lái)：In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task.

模式和范例的區(qū)別在于前者可以直接應(yīng)用到具體的應(yīng)用上，而后者則僅僅提供一些基本的指導(dǎo)方針。在我看來(lái)MVC是一個(gè)很寬泛的概念，任何基于Model、View和Controller對(duì)UI應(yīng)用進(jìn)行分解的設(shè)計(jì)都可以成為MVC。當(dāng)我們采用MVC的思想來(lái)設(shè)計(jì)UI應(yīng)用的時(shí)候，應(yīng)該根據(jù)應(yīng)用框架（比如Windows Forms、WPF和Web Forms）的特點(diǎn)對(duì)Model、View和Controller的界限以及相互之間的交互設(shè)置一個(gè)更為嚴(yán)格的規(guī)則。在軟件設(shè)計(jì)的發(fā)展歷程中出現(xiàn)了一些MVC的變體（Varation），它們遵循定義在MVC中的基本原理。我們現(xiàn)在來(lái)簡(jiǎn)單地討論一些一個(gè)常用的MVC變體。

1.?MVP

MVP是一種廣泛使用的基于架構(gòu)模式，使用與基于事件驅(qū)動(dòng)的應(yīng)用框架，比如ASP.NET Web Forms和Windows Forms應(yīng)用。MVP中的M和V對(duì)應(yīng)中MVC的Model和View，而P（Presenter）則自然代替了MVC中的Controller。但是MVP并非僅僅體現(xiàn)在從Controller到Presenter的轉(zhuǎn)換，更對(duì)地體現(xiàn)在Model、View和Presenter之間的交互上。

MVC模式中元素之間混亂的交互只要體現(xiàn)在允許View和Model繞開(kāi)Controller進(jìn)行單獨(dú)“交流”，這在MVP模式中得到了徹底地解決。如下圖所示，能夠與Model直接進(jìn)行交互的僅限于Presenter，View只能間接地通過(guò)Presenter調(diào)用Model。Model的獨(dú)立性在這里得到了真正的體現(xiàn)，它不僅僅與可視化元素的呈現(xiàn)無(wú)關(guān)（View）和與UI處理邏輯（Presenter）無(wú)關(guān)。使用MVP的應(yīng)用是用戶驅(qū)動(dòng)的而非Model驅(qū)動(dòng)的，所以Model不需要主動(dòng)通知View以提醒狀態(tài)發(fā)生了改變。

MVP不僅僅避免了View和Model之間的耦合，更進(jìn)一步地降低Presenter對(duì)View的依賴(lài)。如圖1-2所示，Presenter依賴(lài)的是一個(gè)抽象化的View，即View實(shí)現(xiàn)的接口IView。這帶來(lái)的最直接的好處就是使定義在Presenter中的UI處理邏輯變得易于測(cè)試。由于Presenter對(duì)View的依賴(lài)行為定義在接口IView中，我們只需要Mock一個(gè)實(shí)現(xiàn)了該接口的View就能對(duì)Presenter進(jìn)行測(cè)試。

構(gòu)成MVP三要素之間的交互體現(xiàn)在兩個(gè)方面，即View/Presenter和Presenter/Model。Presenter和Model之間的交互很清晰，僅僅體現(xiàn)在Presenter對(duì)Model的單向調(diào)用。而View和Presenter之間該采用怎樣的交互方式是整個(gè)MVP的核心，MVP針對(duì)關(guān)注點(diǎn)分離的初衷能否體現(xiàn)在具體的應(yīng)用中很大程度上取決于兩者之間的交互方式是否正確。按照View和Presenter之間的交互方式以及View本身的職責(zé)范圍，Martin Folwer將MVP可分為PV（Passive View）和SoC（Supervising Controller）兩種模式。

(1).PV與SoC

解決View難以測(cè)試的最好的辦法就是讓它無(wú)須測(cè)試，如果View不需要測(cè)試，其先決條件就是讓它盡可能不涉及到UI處理邏輯，而這就是PV模式目的所在。顧名思義，PV（Passive View）是一個(gè)被動(dòng)的View，針對(duì)包含其中的UI元素（比如控件）的操作不是由View自身來(lái)操作，而交給Presenter來(lái)操控。

如果我們純粹地采用PV模式來(lái)設(shè)計(jì)View，意味著我們需要將定義View中的UI元素通過(guò)屬性的形式暴露出來(lái)。具體來(lái)說(shuō)，當(dāng)我們?cè)跒閂iew定義接口的時(shí)候，需要定義基于UI元素的屬性以使Presenter可以對(duì)View進(jìn)行細(xì)粒度地操作，但這并不是意味著我們直接將View上的控件暴露出來(lái)。舉個(gè)簡(jiǎn)單的例子，我們開(kāi)發(fā)的HR系統(tǒng) 中具有如下圖所示的Web頁(yè)面用于根據(jù)部門(mén)獲取員工列表。

現(xiàn)在通過(guò)ASP.NET Web Form應(yīng)用來(lái)涉及這個(gè)頁(yè)面，我們來(lái)討論一下如果采用PV模式View的接口該如何定義。對(duì)于Presenter來(lái)說(shuō)，View供它操作的控件有兩個(gè)，一個(gè)是包含所有部門(mén)列表的DropDownList，另一個(gè)則是顯示員工列表的GridView。在頁(yè)面加載的時(shí)候，Presenter將部門(mén)列表綁定在DropDownList上，與此同時(shí)包含所有員工的列表被綁定到GridView。當(dāng)用戶選擇某個(gè)部門(mén)并點(diǎn)擊“查詢(xún)”按鈕后，View將包含篩選部門(mén)在內(nèi)的查詢(xún)請(qǐng)求轉(zhuǎn)發(fā)給Presenter，后者篩選出相應(yīng)的員工列表之后將其綁定到GridView。

如果我們?yōu)樵揤iew定義一個(gè)接口IEmployeeSearchView，我們不能像如下的代碼所示將上述這兩個(gè)控件直接以屬性的形式暴露出來(lái)。針對(duì)數(shù)據(jù)綁定對(duì)控件類(lèi)型的選擇屬于View的內(nèi)部細(xì)節(jié)（比如說(shuō)針對(duì)部門(mén)列表的顯示，我們可以選擇DropDownList也可以選擇ListBox），不能體現(xiàn)在表示用于抽象View的接口中。在另一方面，理想情況下定義在Presenter中的UI處理邏輯應(yīng)該是與具體的技術(shù)平臺(tái)無(wú)關(guān)的，如果在接口中涉及到了控件類(lèi)型，這無(wú)疑將Presenter也具體的技術(shù)平臺(tái)綁定在了一起。

1: public interface IEmployeeSearchView2: {3: DropDownList Departments { get;}4: GridView Employees { get; }5: }

正確的接口和實(shí)現(xiàn)該接口的View（一個(gè)Web頁(yè)面）應(yīng)該采用如下的定義方式。Presenter通過(guò)屬性Departments和Employees進(jìn)行賦值進(jìn)而實(shí)現(xiàn)對(duì)DropDownList和GridView進(jìn)行綁定，通過(guò)屬性SelectedDepartment得到用戶選擇的篩選部門(mén)。為了盡可能讓接口只暴露必須的信息，我們特意將對(duì)屬性的讀寫(xiě)作了控制。

1:public interface IEmployeeSearchView2: {3: IEnumerable<string> Departments { set; }4: string SelectedDepartment { get; }5: IEnumerable<Employee> Employees { set; }6: }7: 8: public partial class EmployeeSearchView: Page, IEmployeeSearchView9: {10: //其他成員11: public IEnumerable<string> Departments12: {13: set 14: {15: this.DropDownListDepartments.DataSource = value;16: this.DropDownListDepartments.DataBind();17: }18: }19: public string SelectedDepartment20: {21: get { return this.DropDownListDepartments.SelectedValue;}22: }23: public IEnumerable<Employee> Employees24: { 25: set26: {27: this.GridViewEmployees.DataSource = value;28: this.GridViewEmployees.DataBind();29: }30: }31: }

雖然從可測(cè)試性的角度來(lái)說(shuō)PV模式是一種不錯(cuò)的選擇，因?yàn)樗械腢I處理邏輯全部定義在Presenter上，意味著所有的UI處理邏輯都可以被測(cè)試。但是我們需要將View可供操作的UI元素定義在對(duì)應(yīng)的接口中，對(duì)于一些復(fù)雜的富客戶端（Rich Client）View來(lái)說(shuō)，接口成員將會(huì)變得很多，這無(wú)疑會(huì)提升編程所需的代碼量。從另一方講，由于Presenter需要在控件級(jí)別對(duì)View進(jìn)行細(xì)粒度的控制，這無(wú)疑會(huì)提供Presenter本身的復(fù)雜度，往往會(huì)使原本簡(jiǎn)單的邏輯復(fù)雜化，在這種情況下我們往往采用SoC模式。

在SoC（Supervising Controller）模式下，為了降低Presenter的復(fù)雜度，我們將諸如數(shù)據(jù)綁定和格式化這樣簡(jiǎn)單的UI處理邏輯邏輯轉(zhuǎn)移到View中，這些處理邏輯會(huì)體現(xiàn)在View實(shí)現(xiàn)的接口中。盡管View從Presenter中接管了部分UI處理邏輯，但是Presenter依然是整個(gè)三角關(guān)系的驅(qū)動(dòng)者，View被動(dòng)的地位依然沒(méi)有改變。對(duì)于用戶作用在View上的交互操作，View本身并不進(jìn)行響應(yīng)，而是直接將交互請(qǐng)求轉(zhuǎn)發(fā)給Presenter，后者在獨(dú)立完成相應(yīng)的處理流程（可能涉及到針對(duì)Model的調(diào)用）之后會(huì)驅(qū)動(dòng)View或者創(chuàng)建新的View作為對(duì)用戶交互操作的響應(yīng)。

(2).View和Presenter交互的規(guī)則（針對(duì)SoC模式）

View和Presenter之間的交互是整個(gè)MVP的核心，能夠正確地應(yīng)用MVP模式來(lái)架構(gòu)我們的應(yīng)用極大地取決于能夠正確地處理View和Presenter兩者之間的關(guān)系。在由Model、View和Presenter組成的三角關(guān)系的核心不是View而是Presenter，Presenter不是View調(diào)用Model的中介，而是最終決定如何響應(yīng)用戶交互行為的決策者。

打個(gè)比方，View是Presenter委派到前端的客戶代理，而作為客戶的自然就是最終的用戶。對(duì)于以鼠標(biāo)/鍵盤(pán)操作體現(xiàn)的交互請(qǐng)求應(yīng)該如何處理，作為代理的View并沒(méi)有決策權(quán)，所以它會(huì)將請(qǐng)求匯報(bào)給委托人Presenter。View向Presenter發(fā)送用戶交互請(qǐng)求應(yīng)該采用這樣的口吻：“我現(xiàn)在將用戶交互請(qǐng)求發(fā)送給你，你看著辦，需要我的時(shí)候我會(huì)協(xié)助你”，而不應(yīng)該是這樣：“我現(xiàn)在處理用戶交互請(qǐng)求了，我知道該怎么辦，但是我需要你的支持，因?yàn)閷?shí)現(xiàn)業(yè)務(wù)邏輯的Model只信任你”。

對(duì)于Presenter處理用戶交互請(qǐng)求的流程，如果中間環(huán)節(jié)需要涉及到Model，它會(huì)直接發(fā)起對(duì)Model的調(diào)用。如果需要View的參與（比如需要將Model最新的狀態(tài)反應(yīng)在View上），Presenter會(huì)驅(qū)動(dòng)View完成相應(yīng)的工作。

對(duì)于綁定到View上的數(shù)據(jù)，不應(yīng)該是View從Presenter上“拉”回來(lái)的，應(yīng)該是Presenter主動(dòng)“推”給View的。從消息流（或者消息交換模式）的角度來(lái)講，不論是View向Presenter完成針對(duì)用戶交互請(qǐng)求的同志，還是Presenter在進(jìn)行交互請(qǐng)求處理過(guò)程中驅(qū)動(dòng)View完成相應(yīng)的UI操作，都是單向（One-Way）的。反應(yīng)在 應(yīng)用編程接口的定義上就意味著不論是定義在Presenter中被View調(diào)用的方法，還是定義在IView接口中被Presenter調(diào)用的方法最好都是沒(méi)有返回值得。如果不采用方法調(diào)用的形式，我們也可以通過(guò)事件注冊(cè)的方式實(shí)現(xiàn)View和Presenter的交互，事件機(jī)制體現(xiàn)的消息流無(wú)疑是單向的。

View本身僅僅實(shí)現(xiàn)單純的、獨(dú)立的UI處理邏輯，它處理的數(shù)據(jù)應(yīng)該是Presenter實(shí)時(shí)推送給它的，所以View盡可能不維護(hù)數(shù)據(jù)狀態(tài)。定義在IView的接口最好只包含方法，而避免屬性的定義，Presenter所需的關(guān)于View的狀態(tài)應(yīng)該在接收到View發(fā)送的用戶交互請(qǐng)求的時(shí)候一次得到，而不需要通過(guò)View的屬性去獲取。

(3).實(shí)例演示：SoC模式的應(yīng)用

為了讓讀者對(duì)MVP模式，尤其是該模式下的View和Presenter之間的交互方式具有一個(gè)深刻的認(rèn)識(shí)，我們現(xiàn)在來(lái)進(jìn)行一個(gè)簡(jiǎn)單的實(shí)例演示。本實(shí)例采用上面提及的關(guān)于員工查詢(xún)的場(chǎng)景，并且采用ASP.NET Web Form來(lái)建立這個(gè)簡(jiǎn)單的應(yīng)用，最終呈現(xiàn)出來(lái)的效果如上圖所示。前面我們已經(jīng)演示了采用PV模式下的IView應(yīng)該如何定義，現(xiàn)在我們來(lái)看看SoC模式下的IView有何不同。先來(lái)看看表示員工信息的數(shù)據(jù)類(lèi)型如何定義，我們通過(guò)具有如下定義的數(shù)據(jù)類(lèi)型Employee來(lái)表示一個(gè)員工。簡(jiǎn)單起見(jiàn)，我們僅僅定義了表示員工基本信息（ID、姓名、性別、出生日期和部門(mén)）的5個(gè)屬性。

1: public class Employee2: {3: public string Id { get; private set; }4: public string Name { get; private set; }5: public string Gender { get; private set; }6: public DateTime BirthDate { get; private set; }7: public string Department { get; private set; }8: 9: public Employee(string id, string name, string gender, DateTime birthDate, string department)10: { 11: this.Id = id;12: this.Name = name;13: this.Gender = gender;14: this.BirthDate = birthDate;15: this.Department = department;16: }17: }

作為包含應(yīng)用狀態(tài)和狀態(tài)操作行為的Model通過(guò)如下一個(gè)簡(jiǎn)單的EmployeeRepository類(lèi)型還體現(xiàn)。如代碼所示，表示所有員工列表的數(shù)據(jù)通過(guò)一個(gè)靜態(tài)字段來(lái)維護(hù)，而GetEmployees返回指定部門(mén)的員工列表。如果沒(méi)有指定篩選部門(mén)或者指定的部門(mén)字符為空，則直接返回所有的員工列表。

1: public class EmployeeRepository2: {3: private static IList<Employee> employees;4: static EmployeeRepository()5: {6: employees = new List<Employee>();7: employees.Add(new Employee("001", "張三", "男", new DateTime(1981, 8, 24), "銷(xiāo)售部"));8: employees.Add(new Employee("002", "李四", "女", new DateTime(1982, 7, 10), "人事部"));9: employees.Add(new Employee("003", "王五", "男", new DateTime(1981, 9, 21), "人事部"));10: }11: public IEnumerable<Employee> GetEmployees(string department = "")12: {13: if (string.IsNullOrEmpty(department))14: {15: return employees;16: }17: return employees.Where(e => e.Department == department).ToArray();18: }19: }

接下來(lái)我們來(lái)看作為View接口的IEmployeeSearchView的定義。如下面的代碼片斷所示，該接口定義了BindEmployees和BindDepartments兩個(gè)方法，分別用于綁定基于部門(mén)列表的DropDownList和基于員工列表的DataView。除此之外，IEmployeeSearchView接口還定義了一個(gè)事件DepartmentSelected，該事件會(huì)在用戶選擇了篩選部門(mén)后點(diǎn)擊“查詢(xún)”按鈕時(shí)觸發(fā)。DepartmentSelected事件參數(shù)類(lèi)型為自定義的DepartmentSelectedEventArgs，屬性Department表示用戶選擇部門(mén)。

1: public interface IEmployeeSearchView2: {3: void BindEmployees(IEnumerable<Employee> employees);4: void BindDepartments(IEnumerable<string> departments);5: event EventHandler<DepartmentSelectedEventArgs> DepartmentSelected;6: }7: 8: public class DepartmentSelectedEventArgs : EventArgs9: {10: public string Department { get; private set; }11: public DepartmentSelectedEventArgs(string department)12: {13: Guard.ArgumentNotNullOrEmpty(department, "department");14: this.Department = department;15: }16: }

作為MVP三角關(guān)系核心的Presenter通過(guò)具有如下定義的EmployeeSearchPresenter表示。如下面的代碼片斷所示，表示View的只讀屬性類(lèi)型為IEmployeeSearchView接口，而另一個(gè)只讀屬性Repository則表示作為Model的EmployeeRepository對(duì)象，兩個(gè)屬性均在構(gòu)造函數(shù)中初始化。

1: public class EmployeeSearchPresenter2: {3: public IEmployeeSearchView View { get; private set; }4: public EmployeeRepository Repository { get; private set; }5: 6: public EmployeeSearchPresenter(IEmployeeSearchView view)7: {8: this.View = view;9: this.Repository = new EmployeeRepository();10: this.View.DepartmentSelected += OnDepartmentSelected;11: }12: public void Initialize()13: {14: IEnumerable<Employee> employees = this.Repository.GetEmployees();15: this.View.BindEmployees(employees);16: string[] departments = new string[] { "銷(xiāo)售部", "采購(gòu)部", "人事部", "IT部" };17: this.View.BindDepartments(departments);18: }19: protected void OnDepartmentSelected(object sender, DepartmentSelectedEventArgs args)20: {21: string department = args.Department;22: var employees = this.Repository.GetEmployees(department);23: this.View.BindEmployees(employees);24: }25: }

在構(gòu)造函數(shù)中我們注冊(cè)了View的DepartmentSelected事件，作為事件處理器的OnDepartmentSelected方法通過(guò)調(diào)用Repository（即Model）實(shí)現(xiàn)了針對(duì)所選部門(mén)的篩選，而返回的員工列表通過(guò)調(diào)用View的BindEmployees方法實(shí)現(xiàn)了在View上的數(shù)據(jù)綁定。在Initialize方法中，我們通過(guò)調(diào)用Repository獲取了表示所有員工的列表，并通過(guò)View的BindEmployees方法顯示在界面上；通過(guò)調(diào)用View的BindDepartments方法將作為篩選條件的部門(mén)列表綁定在View上。

最后我們來(lái)看看作為View的Web頁(yè)面如何定義，如下所示的是作為頁(yè)面主體部分的HTML，核心部分之包括一個(gè)用于綁定篩選部門(mén)列表的DropDownList和一個(gè)綁定員工列表的GridView。

1: <html xmlns="http://www.w3.org/1999/xhtml">2: <head runat="server">3: ...4: </head>5: <body>6: <form id="form1" runat="server">7: <div id="page">8: <div class="top">9: 選擇查詢(xún)部門(mén)：10: <asp:DropDownList ID="DropDownListDepartments" runat="server" />11: <asp:Button ID="ButtonSearch" runat="server" Text="查詢(xún)" OnClick="ButtonSearch_Click" />12: </div>13: <asp:GridView ID="GridViewEmployees" runat="server" AutoGenerateColumns="false" Width="100%">14: <Columns>15: <asp:BoundField DataField="Name" HeaderText="姓名" />16: <asp:BoundField DataField="Gender" HeaderText="性別" />17: <asp:BoundField DataField="BirthDate" HeaderText="出生日期" DataFormatString="{0:dd/MM/yyyy}" />18: <asp:BoundField DataField="Department" HeaderText="部門(mén)"/>19: </Columns>20: </asp:GridView>21: </div>22: </form>23: </body>24: </html>

如下所示的是該Web頁(yè)面的后臺(tái)代碼的定義。它實(shí)現(xiàn)了定義在IEmployeeSearchView接口的兩個(gè)方法（BindEmployees和BindDepartments）和一個(gè)事件（DepartmentSelected）。表示Presenter的同名屬性在構(gòu)造函數(shù)中被初始化。在頁(yè)面加載的時(shí)候（Page_Load方法）Presenter的Initialize方法被調(diào)用，而在“查詢(xún)”按鈕被點(diǎn)擊的時(shí)候（ButtonSearch_Click）事件DepartmentSelected被觸發(fā)。

1: public partial class Default : Page, IEmployeeSearchView2: {3: public EmployeeSearchPresenter Presenter { get; private set; }4: public event EventHandler<DepartmentSelectedEventArgs> DepartmentSelected;5: public Default()6: {7: this.Presenter = new EmployeeSearchPresenter(this);8: }9: protected void Page_Load(object sender, EventArgs e)10: {11: if (!this.IsPostBack)12: {13: this.Presenter.Initialize();14: }15: }16: public void BindEmployees(IEnumerable<Employee> employees)17: {18: this.GridViewEmployees.DataSource = employees;19: this.GridViewEmployees.DataBind();20: }21: public void BindDepartments(IEnumerable<string> departments)22: {23: this.DropDownListDepartments.DataSource = departments;24: this.DropDownListDepartments.DataBind();25: }26: protected void ButtonSearch_Click(object sender, EventArgs e)27: {28: string department = this.DropDownListDepartments.SelectedValue;29: DepartmentSelectedEventArgs eventArgs = new DepartmentSelectedEventArgs(department);30: if (null != DepartmentSelected)31: {32: DepartmentSelected(this, eventArgs);33: }34: }35: } 2.Model2

Trygve M. H. Reenskau當(dāng)初提出的MVC是作為基于GUI的桌面應(yīng)用的架構(gòu)模式，并不太適合Web本身的特性。雖然MVC/MVP也可以直接用于ASP.NET Web Form應(yīng)用，但這是因?yàn)槲④浕谧烂鎽?yīng)用的編程模式 來(lái)設(shè)計(jì)基于Web Form的ASP.NET應(yīng)用框架的。Web應(yīng)用不同于GUI桌面應(yīng)用在于用戶是通過(guò)瀏覽器與應(yīng)用進(jìn)行交互，交互請(qǐng)求和相應(yīng)是通過(guò)HTTP請(qǐng)求和回復(fù)來(lái)完成的。

為了讓MVC能夠Web應(yīng)用提供原生的支持，另一個(gè)被稱(chēng)為Model2 的MVC變體被提出來(lái)，Model2來(lái)源于基于Java的Web應(yīng)用架構(gòu)模式。Java Web應(yīng)用具有兩種基本的架構(gòu)模式，分別被稱(chēng)為Model1和Model2。Model1類(lèi)似于我們前面提及的自治試圖模式，它將數(shù)據(jù)的可視化呈現(xiàn)和用戶交互操作的處理邏輯合并在一起。Model1使用于那些比較簡(jiǎn)單的Web應(yīng)用，對(duì)于相對(duì)復(fù)雜的應(yīng)用應(yīng)該采用Model 2。

為了讓開(kāi)發(fā)者采用相應(yīng)的編程模式進(jìn)行GUI桌面應(yīng)用和Web應(yīng)用的開(kāi)發(fā)，微軟通過(guò)ViewState和Postback對(duì)背后的HTTP請(qǐng)求和回復(fù)機(jī)制進(jìn)行了封裝，使我們能夠像編寫(xiě)Windows Forms應(yīng)用一樣采用事件驅(qū)動(dòng)的方式進(jìn)行ASP.NET Web Forms應(yīng)用的編程。而Model 2采用完全不同的設(shè)計(jì)，它讓開(kāi)發(fā)者直接面向Web，讓他們關(guān)注HTTP的請(qǐng)求和回復(fù)流程，所以Model 2提供對(duì)Web應(yīng)用原生的支持。

對(duì)于Web應(yīng)用來(lái)說(shuō)，和用戶直接交互的UI界面由瀏覽器來(lái)提供，接下來(lái)我們?cè)敿?xì)討論作為MVC的三要素是如何相互協(xié)作對(duì)從瀏覽器發(fā)出的用戶交互請(qǐng)求的響應(yīng)的，下圖所示的序列圖體現(xiàn)了整個(gè)流程的全過(guò)程。

Model 2種一個(gè)HTTP請(qǐng)求的目標(biāo)是Controller中的某個(gè)Action，后者體現(xiàn)為定義在Controller類(lèi)型中的某個(gè)方法，所以對(duì)請(qǐng)求的處理最終體現(xiàn)在對(duì)Controller對(duì)象的激活和對(duì)Action方法的執(zhí)行。一般來(lái)說(shuō)，Controller、Action以及作為Action方法的部分參數(shù)（針對(duì)HTTP-GET）可以直接通過(guò)請(qǐng)求的URL解析出來(lái)。

如上圖所示，我們通過(guò)一個(gè)攔截器（Interceptor）對(duì)抵達(dá)Web服務(wù)器的HTTP請(qǐng)求進(jìn)行攔截。一般的Web應(yīng)用框架都提供了針對(duì)這樣一種攔截機(jī)制，對(duì)于ASP.NET來(lái)說(shuō)，我們可以以HttpModule的形式來(lái)定義這么一個(gè)攔截器。攔截器根據(jù)請(qǐng)求解析出目標(biāo)Controller和對(duì)應(yīng)的Action，Controller被激活之后Action方法被執(zhí)行。對(duì)于需要傳入Action方法的輸入?yún)?shù)，則來(lái)源于請(qǐng)求地址或/和Post的數(shù)據(jù)。

在Controller的Action方法被執(zhí)行過(guò)程中，它可以調(diào)用Model獲取或者改變其狀態(tài)。在Action方法執(zhí)行的最后階段會(huì)選擇相應(yīng)的View，綁定在View上的數(shù)據(jù)來(lái)源Model或者基于顯示要求進(jìn)行得簡(jiǎn)單邏輯計(jì)算，我們有時(shí)候它們成為VM（View Model），即基于View的Model（MVC中的Model是與UI無(wú)關(guān)的）。生成的View最終寫(xiě)入HTTP回復(fù)并最終呈現(xiàn)在用戶的瀏覽器中。

和MVP一樣，Model 2完全隔斷了View和Model之間的聯(lián)系。Controller作為支配者地位在Model 2體現(xiàn)尤為明顯，用戶交互請(qǐng)求不再由View報(bào)告給Controller（Presenter），而是由攔截器直接轉(zhuǎn)發(fā)給Controller。Controller不僅僅決定著Model的調(diào)用，還決定了View的選擇和生成。ASP.NET MVC就是基于Model 2模式設(shè)計(jì)的。

3.ASP.NETMVC與Model2

憑著讀者對(duì)ASP.NET MVC的了解，通過(guò)上面對(duì)Model2模式的介紹，應(yīng)該很清楚地認(rèn)識(shí)到ASP.NET MVC就是根據(jù)Model2模式設(shè)計(jì)的。基于HTTP請(qǐng)求的攔截機(jī)制是通過(guò)一個(gè)自定義的HttpModule和一個(gè)自定義HttpHandler來(lái)實(shí)現(xiàn)的，在本章的最后我們會(huì)通過(guò)一個(gè)例子來(lái)模擬ASP.NET MVC的工作原理。

在上面我們多次強(qiáng)調(diào)MVC的Model是維持應(yīng)用狀態(tài)提供業(yè)務(wù)功能的領(lǐng)域模型，或者是多層架構(gòu)中進(jìn)入業(yè)務(wù)層的入口或者業(yè)務(wù)服務(wù)的代理，但是ASP.NET MVC中的Model還是這個(gè)Model嗎？稍微了解ASP.NET MVC的讀者都知道ASP.NET MVC的Model僅僅是綁定到View上的數(shù)據(jù)而已，它和MVC模式中的Model并不是一回事。由于ASP.NET MVC中的Model是基于View的，我們可以將其稱(chēng)為View Model。

由于ASP.NET MVC只有View Model，所以ASP.NET MVC應(yīng)用框架本社實(shí)際上僅僅關(guān)于View和Controller，真正的Model以及Model和Controller之間的交互體現(xiàn)在我們?nèi)绾蝸?lái)設(shè)計(jì)Controller。我個(gè)人覺(jué)得將用于構(gòu)建ASP.NET MVC的MVC模式成為M(Model)-V(View)-VM(View Model)-C(Controller)也許更為準(zhǔn)確。

博客來(lái)自：Artech的《 MVC、MVP以及Model2[下篇]?》?

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

總結(jié)

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

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