ASP.NET下MVC設計模式的實現

摘要：本文從視圖、控製器、模型三個方麵簡要介紹了在Asp.net環境下,經典MVC設計模式的實現，並討論了MVC設計模式的擴展，最後對MVC的優點及不足之處進行了分析。

關鍵詞：設計模式、視圖、控製器、模型

ASP.NET是微軟最新推出的新型體係結構.NET框架的一部分，它為構造新一代動態網站和基於網絡的分布式應用提供了強有力的支持。與以前的Web開發模型相比，ASP.NET提供了許多重要的優點例如:簡易性；安全性；可管理性等。而且與基於過程的ASP頁麵技術相比，麵向對象技術在ASP.NET中得到了完全實現。用傳統ASP技術建立的Web應用實例中，在頁麵中同時實現顯示，業務邏輯和流程控製，這從工程化的角度考慮，它有許多不足之處。用戶界麵承擔著向用戶顯示問題模型和與用戶進行操作和I/O交互的作用。用戶希望保持交互操作界麵的相對穩定，但更希望根據需要改變和調整顯示的內容和形式。在.NET框架下ASP.NET技術結合MVC設計模式很好地解決了上述問題。

1MVC設計模式簡介

MVC由TrygveReenskaug提出，首先被應用在SmallTalk-80環境中，是許多交互和界麵係統的構成基礎。MVC結構是為那些需要為同樣的數據提供多個視圖的應用程序而設計的，它很好的實現了數據層與表示層的分離。MVC作為一種開發模型，通常用於分布式應用係統的設計和分析中，以及用於確定係統各部分間的組織關係。對於界麵設計可變性的需求，MVC(Model-View-Controller)把交互係統的組成分解成模型、視圖、控製器三種部件。

視圖部件把表示模型數據及邏輯關係和狀態的信息以特定形式展示給用戶。它從模型獲得顯示信息，對於相同的信息可以有多個不同的顯示形式或視圖。

控製器部件是處理用戶與軟件的交互操作的，其職責是控製提供模型中任何變化的傳播，確保用戶界麵於模型間的對應聯係；它接受用戶的輸入，將輸入反饋給模型，進而實現對模型的計算控製，是使模型和視圖協調工作的部件。

模型部件保存由視圖顯示，由控製器控製的數據；它封裝了問題的核心數據、邏輯和功能的計算關係，它獨立於具體的界麵表達和I/O操作。

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

2MVC設計模式的實現

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＞
...
＜addverb="*"path="*.ASPx"type="Sys.UI.HttpCapture,Sys.UI"/＞
...
＜/httphandlers＞

2.3模型

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

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

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

②采用多個控製器；

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

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

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

圖2　視圖、控製器、模型三者之間關係的示意圖

同樣也可以實現其它形式的MVC例如：一個模型、兩個視圖和兩個控製器。從上麵可以看出，通過MVC模式實現的應用程序具有極其良好的可擴展性，是ASP.NET麵向對象編程的未來方向。
4MVC設計模式的優點及不足之處

4.1MVC的優點

MVC的優點體現在以下幾個方麵：

（1）可以為一個模型在運行時同時建立和使用多個視圖。變化-傳播機製可以確保所有相關的視圖及時得到模型數據變化，從而使所有關聯的視圖和控製器做到行為同步。

（2）視圖與控製器的可接插性，允許更換視圖和控製器對象，而且可以根據需求動態的打開或關閉、甚至在運行期間進行對象替換。

（3）模型的可移植性。因為模型是獨立於視圖的，所以可以把一個模型獨立地移植到新的平台工作。需要做的隻是在新平台上對視圖和控製器進行新的修改。

（4）潛在的框架結構。可以基於此模型建立應用程序框架，不僅僅是用在設計界麵的設計中。

4.2MVC的不足之處

MVC的不足體現在以下幾個方麵：

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

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

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

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

5結束語

與軟件所處理問題的內在模型相比較，用戶界麵是需要經常發生變化的，采用MVC設計模式可以在滿足對界麵要求的同時，使軟件的計算模型獨立於界麵的構成。也可以基於此模型建立大型分布式應用程序框架。本文介紹了MVC設計模式的原理；MVC設計模式三個組成構件（模型部件、視圖部件和控製部件）以及在ASP.NET環境下實現基於MVC的應用需要完成的工作；MVC設計模式的擴展；最後對MVC的優點及不足之處進行了分析。