請介紹以下MVC模式

【專家解說】：MVC模式是"Model-View-Controller"的縮寫，中文翻譯為"模式-視圖-控制器"。MVC應(yīng)用程序總是由這三個部分組成。Event(事件)導(dǎo)致Controller改變Model或View，或者同時改變兩者。只要Controller改變了Models的數(shù)據(jù)或者屬性，所有依賴的View都會自動更新。類似的，只要Controller改變了View，View會從潛在的Model中獲取數(shù)據(jù)來刷新自己。MVC模式最早是smalltalk語言研究團提出的，應(yīng)用于用戶交互應(yīng)用程序中。smalltalk語言和java語言有很多相似性,都是面向?qū)ο笳Z言，很自然的SUN在petstore(寵物店)事例應(yīng)用程序中就推薦MVC模式作為開發(fā)Web應(yīng)用的架構(gòu)模式。MVC模式是一種架構(gòu)模式，其實需要其他模式協(xié)作完成。在J2EE模式目錄中，通常采用service to worker模式實現(xiàn)，而service to worker模式可由集中控制器模式，派遣器模式和Page Helper模式組成。而Struts只實現(xiàn)了MVC的View和Controller兩個部分，Model部分需要開發(fā)者自己來實現(xiàn)，Struts提供了抽象類Action使開發(fā)者能將Model應(yīng)用于Struts框架中。 MVC模式是一個復(fù)雜的架構(gòu)模式，其實現(xiàn)也顯得非常復(fù)雜。但是，我們已經(jīng)終結(jié)出了很多可靠的設(shè)計模式，多種設(shè)計模式結(jié)合在一起，使MVC模式的實現(xiàn)變得相對簡單易行。Views可以看作一棵樹，顯然可以用Composite Pattern來實現(xiàn)。Views和Models之間的關(guān)系可以用Observer Pattern體現(xiàn)。Controller控制Views的顯示，可以用Strategy Pattern實現(xiàn)。Model通常是一個調(diào)停者，可采用Mediator Pattern來實現(xiàn)。 現(xiàn)在讓我們來了解一下MVC三個部分在J2EE架構(gòu)中處于什么位置，這樣有助于我們理解MVC模式的實現(xiàn)。MVC與J2EE架構(gòu)的對應(yīng)關(guān)系是:View處于Web Tier或者說是Client Tier，通常是JSP/Servlet，即頁面顯示部分。Controller也處于Web Tier，通常用Servlet來實現(xiàn)，即頁面顯示的邏輯部分實現(xiàn)。Model處于Middle Tier，通常用服務(wù)端的javaBean或者EJB實現(xiàn)，即業(yè)務(wù)邏輯部分的實現(xiàn)。 一、MVC設(shè)計思想 MVC英文即Model-View-Controller，即把一個應(yīng)用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應(yīng)用被分成三個層——模型層、視圖層、控制層。 視圖(View)代表用戶交互界面，對于Web應(yīng)用來說，可以概括為HTML界面，但有可能為XHTML、XML和Applet。隨著應(yīng)用的復(fù)雜性和規(guī)模性，界面的處理也變得具有挑戰(zhàn)性。一個應(yīng)用可能有很多不同的視圖，MVC設(shè)計模式對于視圖的處理僅限于視圖上數(shù)據(jù)的采集和處理，以及用戶的請求，而不包括在視圖上的業(yè)務(wù)流程的處理。業(yè)務(wù)流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數(shù)據(jù)并顯示給用戶，以及將用戶界面的輸入數(shù)據(jù)和請求傳遞給控制和模型。 模型(Model)：就是業(yè)務(wù)流程/狀態(tài)的處理以及業(yè)務(wù)規(guī)則的制定。業(yè)務(wù)流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數(shù)據(jù)，并返回最終的處理結(jié)果。業(yè)務(wù)模型的設(shè)計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應(yīng)用例子，它從應(yīng)用技術(shù)實現(xiàn)的角度對模型做了進一步的劃分，以便充分利用現(xiàn)有的組件，但它不能作為應(yīng)用設(shè)計模型的框架。它僅僅告訴你按這種模型設(shè)計就可以利用某些技術(shù)組件，從而減少了技術(shù)上的困難。對一個開發(fā)者來說，就可以專注于業(yè)務(wù)模型的設(shè)計。MVC設(shè)計模式告訴我們，把應(yīng)用的模型按一定的規(guī)則抽取出來，抽取的層次很重要，這也是判斷開發(fā)人員是否優(yōu)秀的設(shè)計依據(jù)。抽象與具體不能隔得太遠，也不能太近。MVC并沒有提供模型的設(shè)計方法，而只告訴你應(yīng)該組織管理這些模型，以便于模型的重構(gòu)和提高重用性。我們可以用對象編程來做比喻，MVC定義了一個頂級類，告訴它的子類你只能做這些，但沒法限制你能做這些。這點對編程的開發(fā)人員非常重要。 業(yè)務(wù)模型還有一個很重要的模型那就是數(shù)據(jù)模型J 菽P橢饕 甘堤宥韻蟮氖 ?保存（持續(xù)化）。比如將一張訂單保存到數(shù)據(jù)庫，從數(shù)據(jù)庫獲取訂單。我們可以將這個模型單獨列出，所有有關(guān)數(shù)據(jù)庫的操作只限制在該模型中。 控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起，共同完成用戶的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分發(fā)器，選擇什么樣的模型，選擇什么樣的視圖，可以完成什么樣的用戶請求。控制層并不做任何的數(shù)據(jù)處理。例如，用戶點擊一個連接，控制層接受請求后, 并不處理業(yè)務(wù)信息，它只把用戶的信息傳遞給模型，告訴模型做什么，選擇符合要求的視圖返回給用戶。因此，一個模型可能對應(yīng)多個視圖，一個視圖可能對應(yīng)多個模型。 模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數(shù)據(jù)，所有其它依賴于這些數(shù)據(jù)的視圖都應(yīng)反映到這些變化。因此，無論何時發(fā)生了何種數(shù)據(jù)變化，控制器都會將變化通知所有的視圖，導(dǎo)致顯示的更新。這實際上是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關(guān)系和各自的主要功能，如圖1所示。 二、MVC設(shè)計模式的實現(xiàn) 四、MVC的優(yōu)點 大部分用過程語言比如ASP、PHP開發(fā)出來的Web應(yīng)用，初始的開發(fā)模板就是混合層的數(shù)據(jù)編程。例如，直接向數(shù)據(jù)庫發(fā)送請求并用HTML顯示,開發(fā)速度往往比較快,但由于數(shù)據(jù)頁面的分離不是很直接,因而很難體現(xiàn)出業(yè)務(wù)模型的樣子或者模型的重用性。產(chǎn)品設(shè)計彈性力度很小，很難滿足用戶的變化性需求。MVC要求對應(yīng)用分層，雖然要花費額外的工作，但產(chǎn)品的結(jié)構(gòu)清晰，產(chǎn)品的應(yīng)用通過模型可以得到更好地體現(xiàn)。 首先，最重要的是應(yīng)該有多個視圖對應(yīng)一個模型的能力。在目前用戶需求的快速變化下，可能有多種方式訪問應(yīng)用的要求。例如，訂單模型可能有本系統(tǒng)的訂單，也有網(wǎng)上訂單，或者其他系統(tǒng)的訂單，但對于訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設(shè)計模式，一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的復(fù)制，即減少了代碼的維護量，一旦模型發(fā)生改變，也易于維護。 其次，由于模型返回的數(shù)據(jù)不帶任何顯示格式，因而這些模型也可直接應(yīng)用于接口的使用。 再次，由于一個應(yīng)用被分離為三層，因此有時改變其中的一層就能滿足應(yīng)用的改變。一個應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需改動MVC的模型層。 控制層的概念也很有效，由于它把不同的模型和不同的視圖組合在一起完成不同的請求，因此，控制層可以說是包含了用戶請求權(quán)限的概念。 最后，它還有利于軟件工程化管理。由于不同的層各司其職，每一層不同的應(yīng)用具有某些相同的特征，有利于通過工程化、工具化產(chǎn)生管理程序代碼。 五、MVC的不足 MVC的不足體現(xiàn)在以下幾個方面： （1）增加了系統(tǒng)結(jié)構(gòu)和實現(xiàn)的復(fù)雜性。對于簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結(jié)構(gòu)的復(fù)雜性，并可能產(chǎn)生過多的更新操作，降低運行效率。 （2）視圖與控制器間的過于緊密的連接。視圖與控制器是相互分離，但確實聯(lián)系緊密的部件，視圖沒有控制器的存在，其應(yīng)用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。 （3）視圖對模型數(shù)據(jù)的低效率訪問。依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問，也將損害操作性能。 （4） 目前，一般高級的界面工具或構(gòu)造器不支持MVC模式。改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。 ASP.NET提供了一個很好的實現(xiàn)這種經(jīng)典設(shè)計模式的類似環(huán)境。開發(fā)者通過在ASPX頁面中開發(fā)用戶接口來實現(xiàn)視圖；控制器的功能在邏輯功能代碼(.cs)中實現(xiàn)；模型通常對應(yīng)應(yīng)用系統(tǒng)的業(yè)務(wù)部分。在ASP.NET中實現(xiàn)這種設(shè)計而提供的一個多層系統(tǒng)，較經(jīng)典的ASP結(jié)構(gòu)實現(xiàn)的系統(tǒng)來說有明顯的優(yōu)點。將用戶顯示（視圖）從動作（控制器）中分離出來,提高了代碼的重用性。將數(shù)據(jù)（模型）從對其操作的動作（控制器）分離出來可以讓你設(shè)計一個與后臺存儲數(shù)據(jù)無關(guān)的系統(tǒng)。就MVC結(jié)構(gòu)的本質(zhì)而言，它是一種解決耦合系統(tǒng)問題的方法。 2.1 視圖 視圖是模型的表示，它提供用戶交互界面。使用多個包含單顯示頁面的用戶部件，復(fù)雜的Web頁面可以展示來自多個數(shù)據(jù)源的內(nèi)容，并且網(wǎng)頁人員，美工能獨自參與這些Web頁面的開發(fā)和維護。 在ASP.NET下，視圖的實現(xiàn)很簡單?？梢韵耖_發(fā)WINDOWS界面一樣直接在集成開發(fā)環(huán)境下通過拖動控件來完成頁面開發(fā)本。本文中介紹每一個頁面都采用復(fù)合視圖的形式即：一個頁面由多個子視圖(用戶部件)組成；子視圖可以是最簡單HTML 控件、服務(wù)器控件或多個控件嵌套構(gòu)而成的Web自定義控件。頁面都由模板定義，模板定義了頁面的布局，用戶部件的標簽和數(shù)目，用戶指定一個模板，平臺根據(jù)這些信息自動創(chuàng)建頁面。針對靜態(tài)的模板內(nèi)容，如頁面上的站點導(dǎo)航，菜單，友好鏈接，這些使用缺省的模板內(nèi)容配置；針對動態(tài)的模板內(nèi)容(主要是業(yè)務(wù)內(nèi)容)，由于用戶的請求不同，只能使用后期綁定，并且針對用戶的不同，用戶部件的顯示內(nèi)容進行過濾。使用由用戶部件根據(jù)模板配置組成的組合頁面，它增強了可重用性，并原型化了站點的布局。 視圖部分大致處理流程如下：首先，頁面模板定義了頁面的布局；頁面配置文件定義視圖標簽的具體內(nèi)容（用戶部件）；然后，由頁面布局策略類初始化并加載頁面；每個用戶部件根據(jù)它自己的配置進行初始化，加載校驗器并設(shè)置參數(shù)，以及事件的委托等；用戶提交后，通過了表示層的校驗，用戶部件把數(shù)據(jù)自動提交給業(yè)務(wù)實體即模型。 這一部分主要定義了WEB頁面基類Pagebase；頁面布局策略類PageLayout，完成頁面布局，用于加載用戶部件到頁面；用戶部件基類UserControlbase即用戶部件框架，用于動態(tài)加載檢驗部件，以及實現(xiàn)用戶部件的個性化。為了實現(xiàn)WEB應(yīng)用的靈活性，視圖部分也用到了許多配置文件例如：置文件有模板配置、頁面配置、路徑配置、驗證配置等。 2.2 控制器 為了能夠控制和協(xié)調(diào)每個用戶跨越多個請求的處理，控制機制應(yīng)該以集中的方式進行管理。因此，為了達到集中管理的目的引入了控制器。應(yīng)用程序的控制器集中從客戶端接收請求（典型情況下是一個運行瀏覽器的用戶），決定執(zhí)行什么商業(yè)邏輯功能，然后將產(chǎn)生下一步用戶界面的責任委派給一個適當?shù)囊晥D組件。 用控制器提供一個控制和處理請求的集中入口點，它負責接收、截取并處理用戶請求；并將請求委托給分發(fā)者類，根據(jù)當前狀態(tài)和業(yè)務(wù)操作的結(jié)果決定向客戶呈現(xiàn)的視圖。在這一部分主要定義了HttpReqDispatcher(分發(fā)者類)、HttpCapture(請求捕獲者類)、Controller(控制器類)等，它們相互配合來完成控制器的功能。請求捕獲者類捕獲HTTP請求并轉(zhuǎn)發(fā)給控制器類?？刂破黝愂窍到y(tǒng)中處理所有請求的最初入口點?？刂破魍瓿梢恍┍匾奶幚砗蟀颜埱笪薪o分發(fā)者類；分發(fā)者類分發(fā)者負責視圖的管理和導(dǎo)航，它管理將選擇哪個視圖提供給用戶，并提供給分發(fā)資源控制。在這一部分分別采用了分發(fā)者、策略、工廠方法、適配器等設(shè)計模式。 為了使請求捕獲者類自動捕獲用戶請求并進行處理，ASP.NET 提供低級別的請求/響應(yīng) API，使開發(fā)人員能夠使用 .NET 框架類為傳入的 HTTP 請求提供服務(wù)。為此，必須創(chuàng)作支持 System.Web.IHTTPHandler 接口和實現(xiàn) ProcessRequest() 方法的類即：請求捕獲者類，并在web.config 的 ＜httphandlers＞ 節(jié)中添加類。ASP.NET 收到的每個傳入 HTTP 請求最終由實現(xiàn) IHTTPHandler 的類的特定實例來處理。IHttpHandlerFactory 提供了處理 IHttpHandler 實例 URL 請求的實際解析的結(jié)構(gòu)。HTTP 處理程序和工廠在 ASP.NET 配置中聲明為 web.config 文件的一部分。ASP.NET 定義了一個 ＜httphandlers＞ 配置節(jié)，在其中可以添加和移除處理程序和工廠。子目錄繼承 HttpHandlerFactory 和 HttpHandler 的設(shè)置。 HTTP 處理程序和工廠是 ASP.NET 頁框架的主體。工廠將每個請求分配給一個處理程序，后者處理該請求。 例如，在全局 machine.config 文件中，ASP.NET 將所有對 ASPx 文件的請求映射到 HttpCapture類： ＜httphandlers＞ ... ... ＜/httphandlers＞ 2.3 模型 MVC系統(tǒng)中的模型從概念上可以分為兩類――系統(tǒng)的內(nèi)部狀態(tài)和改變系統(tǒng)狀態(tài)的動作。模型是你所有的商業(yè)邏輯代碼片段所在。本文為模型提供了業(yè)務(wù)實體對象和業(yè)務(wù)處理對象：所有的業(yè)務(wù)處理對象都是從Processbase類派生的子類。業(yè)務(wù)處理對象封裝了具體的處理邏輯，調(diào)用業(yè)務(wù)邏輯模型，并且把響應(yīng)提交到合適的視圖組件以產(chǎn)生響應(yīng)。業(yè)務(wù)實體對象可以通過定義屬性描述客戶端表單數(shù)據(jù)。所有業(yè)務(wù)實體對象都Entitybase派生子類對象，業(yè)務(wù)處理對象可以直接對它進行讀寫，而不再需要和request、response對象進行數(shù)據(jù)交互。通過業(yè)務(wù)實體對象實現(xiàn)了對視圖和模型之間交互的支持。實現(xiàn)時把"做什么"（業(yè)務(wù)處理）和"如何做"（業(yè)務(wù)實體）分離。這樣可以實現(xiàn)業(yè)務(wù)邏輯的重用。由于各個應(yīng)用的具體業(yè)務(wù)是不同的，這里不再列舉其具體代碼實例。 三、MVC設(shè)計模式的擴展 通過在ASP.NET中的MVC模式編寫的，具有極其良好的可擴展性。它可以輕松實現(xiàn)以下功能： ①實現(xiàn)一個模型的多個視圖； ②采用多個控制器； ③當模型改變時，所有視圖將自動刷新； ④所有的控制器將相互獨立工作。 這就是MVC模式的好處，只需在以前的程序上稍作修改或增加新的類，即可輕松增加許多程序功能。以前開發(fā)的許多類可以重用，而程序結(jié)構(gòu)根本不再需要改變，各類之間相互獨立，便于團體開發(fā)，提高開發(fā)效率。下面討論如何實現(xiàn)一個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變，與前面的完全一樣，這就是面向?qū)ο缶幊痰暮锰?。對于控制器中的類，只需要增加另一個視圖，并與模型發(fā)生關(guān)聯(lián)即可。該模式下視圖、控制器、模型三者之間的示意圖如圖2所示。 同樣也可以實現(xiàn)其它形式的MVC例如：一個模型、兩個視圖和兩個控制器。從上面可以看出，通過MVC模式實現(xiàn)的應(yīng)用程序具有極其良好的可擴展性，是ASP.NET面向?qū)ο缶幊痰奈磥矸较颉?/div>