初識MVC模式

=============================================================

標題：初識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的困難。