MVC與MVP簡單對比

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

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

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

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

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

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

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

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

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

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

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

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