標籤: 暫無標籤

MVC模式是"Model-View-Controller"的縮寫,中文翻譯為"模式-視圖-控制器"。MVC應用程序總是由這三個部分組成。

1 MVC -MVC模式介紹

Event(事件)導致Controller改變Model或View,或者同時改變兩者。只要Controller改變了Models的數據或者屬性,所有依賴的View都會自動更新。類似的,只要Controller改變了View,View會從潛在的Model中獲取數據來刷新自己。MVC模式最早是smalltalk語言研究團提出的,應用於用戶交互應用程序中。smalltalk語言和java語言有很多相似性,都是面向對象語言,很自然的SUN在petstore(寵物店)事例應用程序中就推薦MVC模式作為開發Web應用的架構模式。MVC模式是一種架構模式,其實需要其他模式協作完成。在J2EE模式目錄中,通常採用service to worker模式實現,而service to worker模式可由集中控制器模式,派遣器模式和Page Helper模式組成。而Struts只實現了MVC的View和Controller兩個部分,Model部分需要開發者自己來實現,Struts提供了抽象類Action使開發者能將Model應用於Struts框架中。

      MVC模式是一個複雜的架構模式,其實現也顯得非常複雜。但是,我們已經終結出了很多可靠的設計模式,多種設計模式結合在一起,使MVC模式的實現變得相對簡單易行。Views可以看作一棵樹,顯然可以用Composite Pattern來實現。Views和Models之間的關係可以用Observer Pattern體現。Controller控制Views的顯示,可以用Strategy Pattern實現。Model通常是一個調停者,可採用Mediator Pattern來實現。

      現在讓我們來了解一下MVC三個部分在J2EE架構中處於什麼位置,這樣有助於我們理解MVC模式的實現。MVC與J2EE架構的對應關係是:View處於Web Tier或者說是Client Tier,通常是JSP/Servlet,即頁面顯示部分。Controller也處於Web Tier,通常用Servlet來實現,即頁面顯示的邏輯部分實現。Model處於Middle Tier,通常用服務端的javaBean或者EJB實現,即業務邏輯部分的實現。

2 MVC -一、MVC設計思想

  MVC英文即Model-View-Controller,即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離,這樣一個應用被分成三個層——模型層、視圖層、控制層。   

視圖

  視圖(View)代表用戶交互界面,對於Web應用來說,可以概括為HTML界面,但有可能為XHTML、XML和Applet。隨著應用的複雜性和規模性,界面的處理也變得具有挑戰性。一個應用可能有很多不同的視圖,MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理,以及用戶的請求,而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數據並顯示給用戶,以及將用戶界面的輸入數據和請求傳遞給控制和模型。   

模型

  模型(Model):就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來說是黑箱操作,模型接受視圖請求的數據,並返回最終的處理結果。業務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子,它從應用技術實現的角度對模型做了進一步的劃分,以便充分利用現有的組件,但它不能作為應用設計模型的框架。它僅僅告訴你按這種模型設計就可以利用某些技術組件,從而減少了技術上的困難。對一個開發者來說,就可以專註於業務模型的設計。MVC設計模式告訴我們,把應用的模型按一定的規則抽取出來,抽取的層次很重要,這也是判斷開發人員是否優秀的設計依據。抽象與具體不能隔得太遠,也不能太近。MVC並沒有提供模型的設計方法,而只告訴你應該組織管理這些模型,以便於模型的重構和提高重用性。我們可以用對象編程來做比喻,MVC定義了一個頂級類,告訴它的子類你只能做這些,但沒法限制你能做這些。這點對編程的開發人員非常重要。

  業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據 保存(持續化)。比如將一張訂單保存到資料庫,從資料庫獲取訂單。我們可以將這個模型單獨列出,所有有關資料庫的操作只限制在該模型中。

控制

  控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起,共同完成用戶的請求。劃分控制層的作用也很明顯,它清楚地告訴你,它就是一個分發器,選擇什麼樣的模型,選擇什麼樣的視圖,可以完成什麼樣的用戶請求。控制層並不做任何的數據處理。例如,用戶點擊一個連接,控制層接受請求后, 並不處理業務信息,它只把用戶的信息傳遞給模型,告訴模型做什麼,選擇符合要求的視圖返回給用戶。因此,一個模型可能對應多個視圖,一個視圖可能對應多個模型。

模型、視圖與控制器的分離,使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數據,所有其它依賴於這些數據的視圖都應反映到這些變化。因此,無論何時發生了何種數據變化,控制器都會將變化通知所有的視圖,導致顯示的更新。這實際上是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關係和各自的主要功能,如圖1所示。

MVC

3 MVC -二、MVC設計模式的實現

  ASP.NET提供了一個很好的實現這種經典設計模式的類似環境。開發者通過在ASPX頁面中開發用戶介面來實現視圖;控制器的功能在邏輯功能代碼(.cs)中實現;模型通常對應應用系統的業務部分。在ASP.NET中實現這種設計而提供的一個多層系統,較經典的ASP結構實現的系統來說有明顯的優點。將用戶顯示(視圖)從動作(控制器)中分離出來,提高了代碼的重用性。將數據(模型)從對其操作的動作(控制器)分離出來可以讓你設計一個與後台存儲數據無關的系統。就MVC結構的本質而言,它是一種解決耦合系統問題的方法。

2.1 視圖

  視圖是模型的表示,它提供用戶交互界面。使用多個包含單顯示頁面的用戶部件,複雜的Web頁面可以展示來自多個數據源的內容,並且網頁人員,美工能獨自參與這些Web頁面的開發和維護。

  在ASP.NET下,視圖的實現很簡單。可以像開發WINDOWS界面一樣直接在集成開發環境下通過拖動控制項來完成頁面開發本。本文中介紹每一個頁面都採用複合視圖的形式即:一個頁面由多個子視圖(用戶部件)組成;子視圖可以是最簡單HTML 控制項、伺服器控制項或多個控制項嵌套構而成的Web自定義控制項。頁面都由模板定義,模板定義了頁面的布局,用戶部件的標籤和數目,用戶指定一個模板,平台根據這些信息自動創建頁面。針對靜態的模板內容,如頁面上的站點導航,菜單,友好鏈接,這些使用預設的模板內容配置;針對動態的模板內容(主要是業務內容),由於用戶的請求不同,只能使用後期綁定,並且針對用戶的不同,用戶部件的顯示內容進行過濾。使用由用戶部件根據模板配置組成的組合頁面,它增強了可重用性,並原型化了站點的布局。

  視圖部分大致處理流程如下:首先,頁面模板定義了頁面的布局;頁面配置文件定義視圖標籤的具體內容(用戶部件);然後,由頁面布局策略類初始化並載入頁面;每個用戶部件根據它自己的配置進行初始化,載入校驗器並設置參數,以及事件的委託等;用戶提交后,通過了表示層的校驗,用戶部件把數據自動提交給業務實體即模型。

  這一部分主要定義了WEB頁面基類PageBase;頁面布局策略類PageLayout,完成頁面布局,用於載入用戶部件到頁面;用戶部件基類UserControlBase即用戶部件框架,用於動態載入檢驗部件,以及實現用戶部件的個性化。為了實現WEB應用的靈活性,視圖部分也用到了許多配置文件例如:置文件有模板配置、頁面配置、路徑配置、驗證配置等。

2.2 控制器

  為了能夠控制和協調每個用戶跨越多個請求的處理,控制機制應該以集中的方式進行管理。因此,為了達到集中管理的目的引入了控制器。應用程序的控制器集中從客戶端接收請求(典型情況下是一個運行瀏覽器的用戶),決定執行什麼商業邏輯功能,然後將產生下一步用戶界面的責任委派給一個適當的視圖組件。

  用控制器提供一個控制和處理請求的集中入口點,它負責接收、截取並處理用戶請求;並將請求委託給分發者類,根據當前狀態和業務操作的結果決定向客戶呈現的視圖。在這一部分主要定義了HttpReqDispatcher(分發者類)、HttpCapture(請求捕獲者類)、Controller(控制器類)等,它們相互配合來完成控制器的功能。請求捕獲者類捕獲HTTP請求並轉發給控制器類。控制器類是系統中處理所有請求的最初入口點。控制器完成一些必要的處理后把請求委託給分發者類;分發者類分發者負責視圖的管理和導航,它管理將選擇哪個視圖提供給用戶,並提供給分發資源控制。在這一部分分別採用了分發者、策略、工廠方法、適配器等設計模式。

  為了使請求捕獲者類自動捕獲用戶請求並進行處理,ASP.NET 提供低級別的請求/響應 API,使開發人員能夠使用 .NET 框架類為傳入的 HTTP 請求提供服務。為此,必須創作支持 System.Web.IHTTPHandler 介面和實現 ProcessRequest() 方法的類即:請求捕獲者類,並在web.config 的 <httphandlers> 節中添加類。ASP.NET 收到的每個傳入 HTTP 請求最終由實現 IHTTPHandler 的類的特定實例來處理。IHttpHandlerFactory 提供了處理 IHttpHandler 實例 URL 請求的實際解析的結構。HTTP 處理程序和工廠在 ASP.NET 配置中聲明為 web.config 文件的一部分。ASP.NET 定義了一個 <httphandlers> 配置節,在其中可以添加和移除處理程序和工廠。子目錄繼承 HttpHandlerFactory 和 HttpHandler 的設置。 HTTP 處理程序和工廠是 ASP.NET 頁框架的主體。工廠將每個請求分配給一個處理程序,後者處理該請求。 例如,在全局 machine.config 文件中,ASP.NET 將所有對 ASPx 文件的請求映射到 HttpCapture類:

<httphandlers>
...
...
</httphandlers>

2.3 模型

  MVC系統中的模型從概念上可以分為兩類――系統的內部狀態和改變系統狀態的動作。模型是你所有的商業邏輯代碼片段所在。本文為模型提供了業務實體對象和業務處理對象:所有的業務處理對象都是從ProcessBase類派生的子類。業務處理對象封裝了具體的處理邏輯,調用業務邏輯模型,並且把響應提交到合適的視圖組件以產生響應。業務實體對象可以通過定義屬性描述客戶端表單數據。所有業務實體對象都EntityBase派生子類對象,業務處理對象可以直接對它進行讀寫,而不再需要和request、response對象進行數據交互。通過業務實體對象實現了對視圖和模型之間交互的支持。實現時把"做什麼"(業務處理)和"如何做"(業務實體)分離。這樣可以實現業務邏輯的重用。由於各個應用的具體業務是不同的,這裡不再列舉其具體代碼實例。

4 MVC -三、MVC設計模式的擴展

  通過在ASP.NET中的MVC模式編寫的,具有極其良好的可擴展性。它可以輕鬆實現以下功能:

  ①實現一個模型的多個視圖;

  ②採用多個控制器;

  ③當模型改變時,所有視圖將自動刷新;

  ④所有的控制器將相互獨立工作。

  這就是MVC模式的好處,只需在以前的程序上稍作修改或增加新的類,即可輕鬆增加許多程序功能。以前開發的許多類可以重用,而程序結構根本不再需要改變,各類之間相互獨立,便於團體開發,提高開發效率。下面討論如何實現一個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變,與前面的完全一樣,這就是面向對象編程的好處。對於控制器中的類,只需要增加另一個視圖,並與模型發生關聯即可。該模式下視圖、控制器、模型三者之間的示意圖如圖2所示。

MVC

  同樣也可以實現其它形式的MVC例如:一個模型、兩個視圖和兩個控制器。從上面可以看出,通過MVC模式實現的應用程序具有極其良好的可擴展性,是ASP.NET面向對象編程的未來方向。

5 MVC -四、MVC的優點

  大部分用過程語言比如ASP、PHP開發出來的Web應用,初始的開發模板就是混合層的數據編程。例如,直接向資料庫發送請求並用HTML顯示,開發速度往往比較快,但由於數據頁面的分離不是很直接,因而很難體現出業務模型的樣子或者模型的重用性。產品設計彈性力度很小,很難滿足用戶的變化性需求。MVC要求對應用分層,雖然要花費額外的工作,但產品的結構清晰,產品的應用通過模型可以得到更好地體現。

  首先,最重要的是應該有多個視圖對應一個模型的能力。在目前用戶需求的快速變化下,可能有多種方式訪問應用的要求。例如,訂單模型可能有本系統的訂單,也有網上訂單,或者其他系統的訂單,但對於訂單的處理都是一樣,也就是說訂單的處理是一致的。按MVC設計模式,一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的複製,即減少了代碼的維護量,一旦模型發生改變,也易於維護。 其次,由於模型返回的數據不帶任何顯示格式,因而這些模型也可直接應用於介面的使用。

  再次,由於一個應用被分離為三層,因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。

  控制層的概念也很有效,由於它把不同的模型和不同的視圖組合在一起完成不同的請求,因此,控制層可以說是包含了用戶請求許可權的概念。

  最後,它還有利於軟體工程化管理。由於不同的層各司其職,每一層不同的應用具有某些相同的特徵,有利於通過工程化、工具化產生管理程序代碼。

6 MVC -五、MVC的不足

  MVC的不足體現在以下幾個方面:

  (1)增加了系統結構和實現的複雜性。對於簡單的界面,嚴格遵循MVC,使模型、視圖與控制器分離,會增加結構的複雜性,並可能產生過多的更新操作,降低運行效率。

  (2)視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離,但確實聯繫緊密的部件,視圖沒有控制器的存在,其應用是很有限的,反之亦然,這樣就妨礙了他們的獨立重用。

  (3)視圖對模型數據的低效率訪問。依據模型操作介面的不同,視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問,也將損害操作性能。

  (4) 目前,一般高級的界面工具或構造器不支持MVC模式。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的,從而造成使用MVC的困難。

上一篇[鍩]    下一篇 [酸鹼]

相關評論

同義詞:暫無同義詞