MVC模式是Model-View-Controller的縮寫，中文翻譯為模式-檢視-控制器。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所示。
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請求並轉發給控制器類。控制器類是系統中處理所有請求的最初入口點。控制器完成一些必要的處理後把請求委託給分發者類；分發者類分發者負責檢視的管理和導航，它管理將選擇哪個檢視提供給使用者，並提供給分發資源控制。在這一部分分別採用了分發者、策略、工廠方法、介面卡等設計模式。
2.3 模型
MVC系統中的模型從概念上可以分為兩類――系統的內部狀態和改變系統狀態的動作。模型是你所有的商業邏輯程式碼片段所在。本文為模型提供了業務實體物件和業務處理物件：所有的業務處理物件都是從ProcessBase類派生的子類。業務處理物件封裝了具體的處理邏輯，呼叫業務邏輯模型，並且把響應提交到合適的檢視元件以產生響應。業務實體物件可以通過定義屬性描述客戶端表單資料。所有業務實體物件都EntityBase派生子類物件，業務處理物件可以直接對它進行讀寫，而不再需要和request、response物件進行資料互動。通過業務實體物件實現了對檢視和模型之間互動的支援。實現時把"做什麼"（業務處理）和"如何做"（業務實體）分離。這樣可以實現業務邏輯的重用。由於各個應用的具體業務是不同的，這裡不再列舉其具體程式碼例項。
三、MVC設計模式的擴充套件
通過在ASP.NET中的MVC模式編寫的，具有極其良好的可擴充套件性。它可以輕鬆實現以下功能：
①實現一個模型的多個檢視；
②採用多個控制器；
③當模型改變時，所有檢視將自動重新整理；
④所有的控制器將相互獨立工作。
四、MVC的優點
大部分用過程語言比如ASP、PHP開發出來的Web應用，初始的開發模板就是混合層的資料程式設計。例如，直接向資料庫傳送請求並用HTML顯示,開發速度往往比較快,但由於資料頁面的分離不是很直接,因而很難體現出業務模型的樣子或者模型的重用性。產品設計彈性力度很小，很難滿足使用者的變化性需求。MVC要求對應用分層，雖然要花費額外的工作，但產品的結構清晰，產品的應用通過模型可以得到更好地體現。
首先，最重要的是應該有多個檢視對應一個模型的能力。在目前使用者需求的快速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其他系統的訂單，但對於訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個檢視即可解決問題。這樣減少了程式碼的複製，即減少了程式碼的維護量，一旦模型發生改變，也易於維護。 其次，由於模型返回的資料不帶任何顯示格式，因而這些模型也可直接應用於介面的使用。
再次，由於一個應用被分離為三層，因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。
控制層的概念也很有效，由於它把不同的模型和不同的檢視組合在一起完成不同的請求，因此，控制層可以說是包含了使用者請求許可權的概念。
最後，它還有利於軟體工程化管理。由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化產生管理程式程式碼。
五、MVC的不足
MVC的不足體現在以下幾個方面：
（1）增加了系統結構和實現的複雜性。對於簡單的介面，嚴格遵循MVC，使模型、檢視與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低執行效率。
（2）檢視與控制器間的過於緊密的連線。檢視與控制器是相互分離，但確實聯絡緊密的部件，檢視沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
（3）檢視對模型資料的低效率訪問。依據模型操作介面的不同，檢視可能需要多次呼叫才能獲得足夠的顯示資料。對未變化資料的不必要的頻繁訪問，也將損害操作效能。
（4） 目前，一般高階的介面工具或構造器不支援MVC模式。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用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所示。
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請求並轉發給控制器類。控制器類是系統中處理所有請求的最初入口點。控制器完成一些必要的處理後把請求委託給分發者類；分發者類分發者負責檢視的管理和導航，它管理將選擇哪個檢視提供給使用者，並提供給分發資源控制。在這一部分分別採用了分發者、策略、工廠方法、介面卡等設計模式。
2.3 模型
MVC系統中的模型從概念上可以分為兩類――系統的內部狀態和改變系統狀態的動作。模型是你所有的商業邏輯程式碼片段所在。本文為模型提供了業務實體物件和業務處理物件：所有的業務處理物件都是從ProcessBase類派生的子類。業務處理物件封裝了具體的處理邏輯，呼叫業務邏輯模型，並且把響應提交到合適的檢視元件以產生響應。業務實體物件可以通過定義屬性描述客戶端表單資料。所有業務實體物件都EntityBase派生子類物件，業務處理物件可以直接對它進行讀寫，而不再需要和request、response物件進行資料互動。通過業務實體物件實現了對檢視和模型之間互動的支援。實現時把"做什麼"（業務處理）和"如何做"（業務實體）分離。這樣可以實現業務邏輯的重用。由於各個應用的具體業務是不同的，這裡不再列舉其具體程式碼例項。
三、MVC設計模式的擴充套件
通過在ASP.NET中的MVC模式編寫的，具有極其良好的可擴充套件性。它可以輕鬆實現以下功能：
①實現一個模型的多個檢視；
②採用多個控制器；
③當模型改變時，所有檢視將自動重新整理；
④所有的控制器將相互獨立工作。
這就是MVC模式的好處，只需在以前的程式上稍作修改或增加新的類，即可輕鬆增加許多程式功能。以前開發的許多類可以重用，而程式結構根本不再需要改變，各類之間相互獨立，便於團體開發，提高開發效率。下面討論如何實現一個模型、兩個檢視和一個控制器的程式。其中模型類及檢視類根本不需要改變，與前面的完全一樣，這就是物件導向程式設計的好處。對於控制器中的類，只需要增加另一個檢視，並與模型發生關聯即可。該模式下檢視、控制器、模型三者之間的示意圖如圖2所示。
四、MVC的優點
大部分用過程語言比如ASP、PHP開發出來的Web應用，初始的開發模板就是混合層的資料程式設計。例如，直接向資料庫傳送請求並用HTML顯示,開發速度往往比較快,但由於資料頁面的分離不是很直接,因而很難體現出業務模型的樣子或者模型的重用性。產品設計彈性力度很小，很難滿足使用者的變化性需求。MVC要求對應用分層，雖然要花費額外的工作，但產品的結構清晰，產品的應用通過模型可以得到更好地體現。
首先，最重要的是應該有多個檢視對應一個模型的能力。在目前使用者需求的快速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其他系統的訂單，但對於訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個檢視即可解決問題。這樣減少了程式碼的複製，即減少了程式碼的維護量，一旦模型發生改變，也易於維護。 其次，由於模型返回的資料不帶任何顯示格式，因而這些模型也可直接應用於介面的使用。
再次，由於一個應用被分離為三層，因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。
控制層的概念也很有效，由於它把不同的模型和不同的檢視組合在一起完成不同的請求，因此，控制層可以說是包含了使用者請求許可權的概念。
最後，它還有利於軟體工程化管理。由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化產生管理程式程式碼。
五、MVC的不足
MVC的不足體現在以下幾個方面：
（1）增加了系統結構和實現的複雜性。對於簡單的介面，嚴格遵循MVC，使模型、檢視與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低執行效率。
（2）檢視與控制器間的過於緊密的連線。檢視與控制器是相互分離，但確實聯絡緊密的部件，檢視沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
（3）檢視對模型資料的低效率訪問。依據模型操作介面的不同，檢視可能需要多次呼叫才能獲得足夠的顯示資料。對未變化資料的不必要的頻繁訪問，也將損害操作效能。
（4） 目前，一般高階的介面工具或構造器不支援MVC模式。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。