MVC與MVP簡(jiǎn)單對(duì)比

1、ZTE*K內(nèi)部公開(kāi) Internal Use OnlyA在Java平臺(tái)，基丁 Spring等技術(shù)的MVCJI架已經(jīng)走向成熟；在.NET平臺(tái)，微 軟也推出了 MVC MVP Framework MVP同丁 MVC勺地方，關(guān)鍵在丁， View不 再顯示的依賴丁 Business Logic Controller ,而是依賴丁一個(gè)業(yè)務(wù)邏輯抽象接 口，關(guān)注丁 View的解藕。所以區(qū)分MV MVC勺關(guān)鍵在丁 View是否依賴丁某一 具體的業(yè)務(wù)對(duì)象。Model View Presenter vs Model View Controller在N層體系結(jié)構(gòu)中MVCP模式僅僅只是用丁表示層(presentati

2、on layer),理解 這一點(diǎn)很重要。這兩個(gè)模式并不是關(guān)丁怎么構(gòu)建數(shù)據(jù)層(data layer)和服務(wù)層(service layer)的，而是關(guān)丁怎么將數(shù)據(jù)(data)從用戶物口 (view)中分離出來(lái)， 以及用戶接口如何與數(shù)據(jù)進(jìn)行交互的。這些模式的使用解除了你的程序中表示層 對(duì)數(shù)據(jù)和控制邏輯的依賴，從而可以自由的變更表示層。MVC(Model View Controller)模式處理過(guò)程1、為了使得視圖接口可以與模型和控制器進(jìn)行交互，控制器執(zhí)行一些初始化事 件2、用戶通過(guò)視圖(用戶接口)執(zhí)行一些操作3、控制器處理用戶行為(可以用觀察著模式實(shí)現(xiàn))并通知模型進(jìn)行更新4、模型引發(fā)一些事件，以便將

3、改變發(fā)告知視圖5、視圖處理模型變更的事件，然后顯示新的模型數(shù)據(jù)6、用戶接口等待用戶的進(jìn)一步操作這一模式的有以下幾個(gè)要點(diǎn)：1、視圖并不使用控制器去更新模型?？刂破髫?fù)責(zé)處理從視圖發(fā)送過(guò)來(lái)的用戶操作并通過(guò)與模型的交互進(jìn)行數(shù)據(jù)的更新2、 控制器可以和視圖融合在一塊。Visual Studio.NET 中對(duì) Windows Forms的默認(rèn)處理方式就是這樣的。【譯注：比如雙擊一個(gè)Button ,然后在它的事件里寫(xiě)處理邏輯，然后將處理的數(shù)據(jù)寫(xiě)回模型中。 這里處理邏輯時(shí)間應(yīng)該是控制器的 功能，但是我們并沒(méi)有專門寫(xiě)一個(gè)控制器來(lái)做這件事情而是接受了VS.NET IDE的默認(rèn)處理方式，將它寫(xiě)在Form的代碼中，而

4、這里的Form在MVO它就是一個(gè) View。所以這說(shuō)VS.NETIDE默認(rèn)的處理方式是將把控制器和視圖融合在一起的。】3、控制器不包含對(duì)視圖的渲染邏輯(rendering logic)生動(dòng)一MVC模式，也是通常意義下的 MVO莫式【譯注：為什么說(shuō)是主動(dòng)的？ View不是等Controller 通知它Model更新了然后 才從Model取數(shù)據(jù)并更新顯示，而是自己監(jiān)視Model的更新(如果用觀察者模式) 或主動(dòng)詢問(wèn)Model是否更新。前面那種等待 Controller通知的方式是下面所介 紹的 被動(dòng)一MVC的實(shí)現(xiàn)方式?！勘粍?dòng)一MVC模式與主動(dòng)MVC勺區(qū)別在丁：1、模型對(duì)視圖和控制器一無(wú)所知，它僅僅

5、是被它們使用2、控制器使用視圖，并通知它更新數(shù)據(jù)顯示3、 視圖僅僅是在控制器通知它去模型取數(shù)據(jù)的時(shí)候它才這么做(視圖并不會(huì)訂閱 或監(jiān)視模型的更新)4、控制器負(fù)責(zé)處理模型數(shù)據(jù)的變化5、控制器可以包含對(duì)視圖的渲染邏輯現(xiàn)在我們來(lái)看看MV®用程序的執(zhí)行過(guò)程：當(dāng)用戶發(fā)出請(qǐng)求時(shí)，請(qǐng)求首先由 UrlRoutingModule 對(duì)象處理，這個(gè)對(duì)象是一個(gè) HTTP莫塊(HTTP module)。這個(gè)對(duì)象在分析請(qǐng)求后，查找第一個(gè)與當(dāng)前請(qǐng)求匹配 的route對(duì)象(route object) 。route 對(duì)象是實(shí)現(xiàn)了 RouteBase的類，通常都 是Route類的實(shí)例。如果沒(méi)找到任何吻合的route對(duì)象

6、，UrlRoutingModule 就不再處理，而由 ASP.NET勺標(biāo)準(zhǔn)流程或IIS繼續(xù)處理。如果找到了一個(gè) Route對(duì)象，UrlRoutingModule 會(huì)從Route對(duì)象中獲取 IRouteHandler 對(duì)象實(shí)例。IRouteHandler 對(duì)象通常都是 MvcRouteHandler 的實(shí) 例，它會(huì)創(chuàng)建IHttpHandler對(duì)象(默認(rèn)情形下就是MvcHandler的實(shí)例)，并傳遞 給IHttpContext 對(duì)象。由MvcHandler的實(shí)例選擇控制器，并最終讓這個(gè)控制 器處理請(qǐng)求。注意：對(duì)丁 IIS6,要把.mvc文件擴(kuò)展名映射到 ASP.NET_ISAPI.DLL IIS7

7、則不用 配置。模塊(module)和處理器(handler)是MVGfif架的入口點(diǎn)，他們負(fù)責(zé)以下工作:從MVC Web用程序挑選恰當(dāng)?shù)目刂破鳙@取特定的控制器對(duì)象實(shí)例*調(diào)用控制器的Execute方法 各執(zhí)行階段的總結(jié)情況如下表所示：第1頁(yè)<以上所有信息均為中興通訊股份有限公司所有，不得外傳>All Rights reserved, No Spreading abroad without Permission of ZTELI CtTX內(nèi)部公開(kāi) Internal Use OnlyA一，首次接收到對(duì)應(yīng)用程序的請(qǐng)求在Global.asax 文件中，Route對(duì)象被加入到RouteTabl

8、e集合。二,route 操作UrlRoutingModule 從 RouteTable 中查找首個(gè)匹配的 Route 對(duì)象，創(chuàng)建 RouteData 對(duì)象，用RouteData對(duì)象創(chuàng)建RequestContext對(duì)象。三，創(chuàng)建MVC#求處理器MvcRouteHandler對(duì)象實(shí)例創(chuàng)建 MvcHandler類的實(shí)例，然后向它傳遞 RequestContext 實(shí)例。四, 創(chuàng)建控制器MvcHandler 通過(guò) RequestContext 實(shí)例找到 IControllerFactory 對(duì)象，用它來(lái) 創(chuàng)建控制器對(duì)象實(shí)例。IControllerFactory對(duì)象通常都是DefaultControll

9、erFactory 的實(shí)例。如果沒(méi)有找到對(duì)應(yīng)的控制器，將返回HTTP500昔誤。五, 執(zhí)行控制器MvcHandler調(diào)用控制器的Execute方法。六，調(diào)用動(dòng)作方法多數(shù)控制器類都是從Controller基類繼承來(lái)的，凡是這類控制器，其內(nèi)部的ControllerActionInvoker對(duì)象負(fù)責(zé)判斷應(yīng)該調(diào)用哪個(gè)動(dòng)作方法，并由它來(lái)調(diào)用。這兩種模式中三個(gè)部分的一般理解1、模型(Model)表示數(shù)據(jù)模型和業(yè)務(wù)邏輯(business logic)。模型并不總是 DataSet, DataTable之類的東西，它代表著一類組件(components)或類(class), 這些組件或類可以向外部提供數(shù)據(jù)，同

10、時(shí)也能從外部獲取數(shù)據(jù)并將這些數(shù)據(jù)存儲(chǔ) 在某個(gè)地方。簡(jiǎn)單的理解，可以把模型想象成 外觀類(facade class) ”?！咀g注： 這里的外觀是指 外觀模式”中所說(shuō)的外觀。外觀的一般作用是為一個(gè)復(fù)雜的子系 統(tǒng)提供高層次的簡(jiǎn)單易用的訪問(wèn)接口】，可以參看下面的圖來(lái)理解它的原理：2、 視圖(View)將數(shù)據(jù)層現(xiàn)給用戶。一般的視圖都只是包含用戶界面 (UI),而不 包含界面邏輯。比如，A中包含控件的頁(yè)面(Page)就是一個(gè)視圖。視圖可 以從模型中讀取數(shù)據(jù)，但是不能修改或更新模型。3、 層現(xiàn)器(Presenter)/控制器(Controller)包含了根據(jù)用戶在視圖中的行為去 更新模型的邏輯。視圖僅僅只是

11、將用戶的行為告知控制器，而控制器負(fù)責(zé)從視圖 中取得數(shù)據(jù)然后發(fā)送給模型。MVC/P模式的核心是為了將模型從視圖/控制器中分離出來(lái)，從而使得模型獨(dú)立 丁它們，因此模型不包含對(duì)視圖和控制的引用。MVPK!式與 被動(dòng)一MVC莫式”很接近，區(qū)別在丁 視圖并不使用模型”。在MVP莫式中視圖 和模型是完全分離的，他們通過(guò) Presenter進(jìn)行交互。Presenter與控制器非常相似，但是它們也有一些的區(qū)別：1、Presenter處理視圖發(fā)送過(guò)來(lái)的用戶操作（在 MV®視圖自己處理了這些操2、 它用更新過(guò)的數(shù)據(jù)去更新模型（在被動(dòng) MVCfr控制器只是通知視圖去更新過(guò) 的模型中去取新的數(shù)據(jù)，而主動(dòng)MV

12、Cfr模型通知視圖去更新顯示，控制器不需要 做工作）3、檢查模型的更新（與被動(dòng) MVC-樣）4、（與MVC勺主要區(qū)別）從模型中取數(shù)據(jù)然后將它們發(fā)送到視圖中5、（與MVC勺主要區(qū)別）將所做的更新告知視圖6、（與MVC勺區(qū)別）用Presenter渲染視圖MVP勺優(yōu)勢(shì)1、模型與視圖完全分離，我們可以修改視圖而不影響模型2、 可以更高效地使用模型，因?yàn)樗缘慕换ザ及l(fā)生在一個(gè)地方 Presenter 內(nèi)部3、 我們可以將一個(gè)Presener用丁多個(gè)視圖，而不需要改變 Presenter的邏輯。 這個(gè)特性非常的有用，因?yàn)橐晥D的變化總是比模型的變化頻繁。4、如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來(lái)測(cè)試這 些邏輯（單元測(cè)試）MVP勺缺點(diǎn)由丁對(duì)視圖的渲染放在了 Presenter中，所以視圖和Persenter的交互會(huì)過(guò)丁頻 繁。還有一點(diǎn)你需要明白，如果Presenter過(guò)多地渲染了視圖，往往會(huì)使得它與 特定