=============================================================
標題：初識MVC模式
備註：截取自百度百科
日期：2011.4.7
姓名：朱銘雷
=============================================================
簡介
MVC架構是"Model-View-Controller"的縮寫，中文翻譯爲"模型-視圖-控制器"。MVC應用程序總是由這三個部分組成。Event(事件)導致Controller改變Model或View，或者同時改變兩者。只要Controller改變了Models的數據或者屬性，所有依賴的View都會自動更新。類似的，只要Controller改變了View，View會從潛在的Model中獲取數據來刷新自己。
關係圖示
MVC架構與設計模式
MVC架構是一個複雜的架構，其實現也顯得非常複雜。但是，我們已經總結出了很多可靠的設計模式，多種設計模式結合在一起，使MVC架構的實現變得相對簡單易行。Views可以看作一棵樹，顯然可以用Composite Pattern來實現。Views和Models之間的關係可以用Observer Pattern體現。Controller控制Views的顯示，可以用Strategy Pattern實現。Model通常是一個調停者，可採用Mediator Pattern來實現。
設計思想
把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離，這樣一個應用被分成三個層——模型層、視圖層、控制層。視圖(View)代表用戶交互界面，一個應用可能有很多不同的視圖，MVC設計模式對於視圖的處理僅限於視圖上數據的採集和處理，以及用戶的請求，而不包括在視圖上的業務流程的處理。業務流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數據並顯示給用戶，以及將用戶界面的輸入數據和請求傳遞給控制和模型。模型(Model)：就是業務流程/狀態的處理以及業務規則的制定。業務流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數據，並返回最終的處理結果。業務模型還有一個很重要的模型那就是數據模型。數據模型主要指實體對象的數據保存（持續化）。比如將一張訂單保存到數據庫，從數據庫獲取訂單。我們可以將這個模型單獨列出，所有有關數據庫的操作只限制在該模型中。控制(Controller)可以理解爲從用戶接收請求, 將模型與視圖匹配在一起，共同完成用戶的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分發器，選擇什麼樣的模型，選擇什麼樣的視圖，可以完成什麼樣的用戶請求。控制層並不做任何的數據處理。例如，用戶點擊一個連接，控制層接受請求後, 並不處理業務信息，它只把用戶的信息傳遞給模型，告訴模型做什麼，選擇符合要求的視圖返回給用戶。因此，一個模型可能對應多個視圖，一個視圖可能對應多個模型。 模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數據，所有其它依賴於這些數據的視圖都應反映到這些變化。因此，無論何時發生了何種數據變化，控制器都會將變化通知所有的視圖，導致顯示的更新。這實際上是一種模型的變化-傳播機制。
實現
ASP NET
asp net提供了一個很好的實現這種經典設計模式的類似環境。開發者通過在ASPX頁面中開發用戶接口來實現視圖；控制器的功能在邏輯功能代碼(.cs)中實現；模型通常對應應用系統的業務部分。
MFC
微軟所推出的MFC Document/View架構是早期對於MVC實現，MFC將程序分成CView以及CDocument兩大類，其中的Document對應MVC中的 Model，View相當於MVC中的View＋Controller，再加上CWinApp類，合成三大項。但是基本上MFC是一個失敗的MVC作品。由於MFC之下的Document/View定義過於模糊，未將Controller（MessageMap）部份取出，因此Controller可以置入View或Document，但不管置入哪一方面，都會與View或Document綁死，沒有彈性。
MVC的優點
例如，訂單模型可能有本系統的訂單，也有網上訂單，或者其他系統的訂單，但對於訂單的處理都是一樣，也就是說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的複製，即減少了代碼的維護量，一旦模型發生改變，也易於維護。其次，由於模型返回的數據不帶任何顯示格式，因而這些模型也可直接應用於接口的使用。再次，由於一個應用被分離爲三層，因此有時改變其中的一層就能滿足應用的改變。一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。控制層的概念也很有效，由於它把不同的模型和不同的視圖組合在一起完成不同的請求，因此，控制層可以說是包含了用戶請求權限的概念。最後，它還有利於軟件工程化管理。由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化產生管理程序代碼。
MVC的不足
（1）增加了系統結構和實現的複雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。
（2）視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯繫緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。 （3）視圖對模型數據的低效率訪問。依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
（4） 目前，一般高級的界面工具或構造器不支持MVC架構。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。