woaidongmao

       MVC(Model-View-Controller)模式的基本思想是數(shù)據(jù)，顯示和處理相分離。模型(Model)負(fù)責(zé)數(shù)據(jù)管理，視圖(View)負(fù)責(zé)數(shù)據(jù)顯示，控制器(Controller)負(fù)責(zé)業(yè)務(wù)邏輯和響應(yīng)策略。
       從MVC的形成過(guò)程來(lái)看，最初只有模型和視圖兩個(gè)元素。模型封裝了數(shù)據(jù)并提供操作接口，視圖用來(lái)表現(xiàn)數(shù)據(jù)和接收用戶請(qǐng)求。模型是獨(dú)立的，而視圖依賴于模型：從模型獲取數(shù)據(jù)進(jìn)行顯示；向模型發(fā)送用戶請(qǐng)求，并根據(jù)返回結(jié)果刷新自己。
       需要用多個(gè)視圖表現(xiàn)同一模型時(shí)，情況發(fā)生了變化：一個(gè)視圖修改數(shù)據(jù)以后，不但本身要刷新，其他所有視圖也要刷新。如果由該視圖通知其他視圖，它就需要知道其他所有視圖，由于每個(gè)視圖都可能發(fā)出修改，每個(gè)視圖都要知道其他所有視圖，這種關(guān)聯(lián)過(guò)于復(fù)雜，不但難以維護(hù)，而且不便于增加新的視圖。如果讓模型通知所有視圖更新，可能會(huì)影響模型的獨(dú)立性。用觀察者(Observer)模式可以解決上述矛盾，從而實(shí)現(xiàn)：由模型通知視圖，而模型不依賴于具體的視圖，具體視圖之間相互獨(dú)立。
       視圖是用戶請(qǐng)求的接收者，但不宜作為請(qǐng)求的處理者。因?yàn)榻缑媸且鬃兊?，如果業(yè)務(wù)代碼和界面代碼放在一起，頻繁的界面修改可能會(huì)破壞比較穩(wěn)定的業(yè)務(wù)代碼。將業(yè)務(wù)邏輯分離出來(lái)，由一個(gè)控制器負(fù)責(zé)，就是為了避免這種干擾。
       模型，視圖和控制器的基本協(xié)作關(guān)系如下圖

       模型在狀態(tài)變化的時(shí)候，直接通知所有視圖，視圖向模型查詢狀態(tài)數(shù)據(jù)，然后刷新自身。當(dāng)用戶發(fā)出操作時(shí)，視圖把消息發(fā)給控制器，控制器按照業(yè)務(wù)邏輯進(jìn)行處理，需要查詢或更新數(shù)據(jù)時(shí)，控制器會(huì)調(diào)用模型。下面是一個(gè)更詳細(xì)的示意圖


       同樣的數(shù)據(jù)，可以有不同的顯示和進(jìn)行各種處理。顯示僅僅是表現(xiàn)數(shù)據(jù)，而處理是根據(jù)用戶請(qǐng)求改變數(shù)據(jù)的過(guò)程，不但包含業(yè)務(wù)邏輯，也要提供響應(yīng)策略。響應(yīng)策略由控制器負(fù)責(zé)，視圖可以使用不同的控制器提供不同的響應(yīng)方式，這是策略(Strategy)模式的應(yīng)用。
       此外，MVC還允許視圖嵌套，通過(guò)使用組合(Composite)模式，一致地處理組合視圖和普通視圖。
       用多個(gè)視圖表現(xiàn)一個(gè)模型，在視圖不變的情況下改變響應(yīng)策略，允許視圖嵌套，這是MVC的三個(gè)主要特性。在內(nèi)部結(jié)構(gòu)上，MVC的主要關(guān)系是由觀察者模式，策略模式和組合模式給出的。由觀察者模式確定的模型視圖關(guān)系是其中最為重要的。
       MVC模式有許多變體。前述結(jié)構(gòu)中，由模型通知視圖刷新，稱為主動(dòng)MVC；如果由控制器更新模型以后通知視圖，稱為被動(dòng)MVC結(jié)構(gòu)。在許多應(yīng)用中，沒(méi)有明顯的控制器角色，也沒(méi)有視圖嵌套。可見(jiàn)根據(jù)實(shí)際需要，構(gòu)成MVC的三個(gè)模式上都可能出現(xiàn)變化。Web瀏覽器就是被動(dòng)MVC結(jié)構(gòu)的一個(gè)實(shí)例。

       “瀏覽器是一個(gè)交互程序，從概念上講，它是由一組客戶、一組解釋器與一個(gè)管理它們的控制器所組成。控制器形成了瀏覽器的中心部件，它解釋鼠標(biāo)點(diǎn)擊與鍵盤輸入，并且調(diào)用其他組件來(lái)執(zhí)行用戶指定的操作。例如，當(dāng)用戶鍵入一個(gè)URL或者點(diǎn)擊一個(gè)超文本引用時(shí)，控制器調(diào)用一個(gè)客戶從所需文檔所在的遠(yuǎn)程服務(wù)器上取回該文檔，并且調(diào)用解釋器向用戶顯示該文檔。每個(gè)瀏覽器必須包含一個(gè)HTML解釋器來(lái)顯示文檔，其他解釋器是可選的。HTML解釋器的輸入由符合HTML語(yǔ)法的文檔所組成，輸出由位于用戶顯示器上的格式版本文檔所組成。解釋器通過(guò)將HTML規(guī)則轉(zhuǎn)換成適合用戶顯示硬件的命令來(lái)處理版面細(xì)節(jié)。HTML解釋器一個(gè)最重要的功能是包含可選項(xiàng)。解釋器必須存儲(chǔ)關(guān)于顯示器上位置之間關(guān)系的信息和HTML文檔中被瞄定的項(xiàng)。當(dāng)用戶用鼠標(biāo)選定了一個(gè)項(xiàng)，瀏覽器通過(guò)當(dāng)前的光標(biāo)位置和存儲(chǔ)的位置信息來(lái)決定哪個(gè)項(xiàng)被用戶選定。”(參考資料5)

       MFC的文檔/視圖結(jié)構(gòu)(Document/View architecture)是MVC模式的一種變體，下面討論它是怎樣實(shí)現(xiàn)的。
       文檔/視圖結(jié)構(gòu)沒(méi)有體現(xiàn)業(yè)務(wù)邏輯和視圖的分離，但是將響應(yīng)策略和視圖區(qū)分開(kāi)來(lái)。它主要包含四種對(duì)象：

1. 文檔

2. 視圖

3. 視圖框架窗口

4. 文檔模板

       這里的視圖框架窗口定義了視圖對(duì)用戶輸入的響應(yīng)方式，而文檔模板用來(lái)管理前三種對(duì)象的組合。文檔，視圖，視圖框架窗口三者是對(duì)應(yīng)的，從而構(gòu)成一個(gè)三元組。一個(gè)應(yīng)用程序可能需要多個(gè)這樣的三元組，以實(shí)現(xiàn)文檔的多視圖，所以引入文檔模板來(lái)表示該三元組。因?yàn)槌绦蛑锌赡苁褂枚鄠€(gè)文檔模板，MFC用一個(gè)文檔管理者對(duì)象來(lái)管理它們。
       在MFC中，應(yīng)用程序和主框架窗口是用來(lái)封裝底層機(jī)制的對(duì)象，文檔，視圖，視圖框架窗口和文檔模板是用來(lái)構(gòu)架文檔/視圖結(jié)構(gòu)的對(duì)象。應(yīng)用程序通過(guò)文檔管理者來(lái)使用文檔/視圖結(jié)構(gòu)。
       如果要給文檔增加一種視圖，只需要增加一個(gè)文檔模板；如果要改變一種視圖的響應(yīng)策略，只要改變對(duì)應(yīng)文檔模板中的視圖框架窗口。

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

       軟件設(shè)計(jì)中會(huì)碰到這樣的關(guān)系：一個(gè)對(duì)象依賴于另一個(gè)對(duì)象，必須根據(jù)后者的狀態(tài)更新自己的狀態(tài)，可以把后者稱作目標(biāo)對(duì)象，前者稱作觀察者對(duì)象。不但觀察者依賴于目標(biāo)，當(dāng)目標(biāo)的狀態(tài)改變時(shí)也要通知觀察者，這就出現(xiàn)了雙向的依賴。兩個(gè)對(duì)象互相依賴的后果是它們必須一起復(fù)用。如果一個(gè)目標(biāo)有多個(gè)觀察者，那么目標(biāo)也依賴所有觀察者，從而目標(biāo)對(duì)象無(wú)法獨(dú)立復(fù)用。如何消除目標(biāo)和觀察者之間的互相依賴呢？觀察者模式幫助我們解決這個(gè)問(wèn)題。
觀察者模式把目標(biāo)對(duì)觀察者的依賴進(jìn)行抽象：使目標(biāo)只知道自己有若干觀察者，但不知道這些觀察者具體是誰(shuí)，可能有多少個(gè)；當(dāng)目標(biāo)狀態(tài)改變時(shí)只要給這些觀察者一個(gè)通知，不必作更多的事情。這樣目標(biāo)對(duì)觀察者的依賴就達(dá)到了抽象和最小，而目標(biāo)對(duì)具體觀察者的依賴被解除了。
       類圖如下：

       Subject對(duì)象保存一個(gè)Observer引用的列表，當(dāng)我們讓一個(gè)ConcreteObserver對(duì)象觀察Subject對(duì)象時(shí)，調(diào)用后者的Attach()方法，將前者的引用加入該列表中。當(dāng)Subject對(duì)象狀態(tài)改變時(shí)，它調(diào)用自身的Notify方法，該方法調(diào)用列表中每一個(gè)Observer的Update()方法。一個(gè)ConcreteObserver只要重定義Update()就能收到通知，作為對(duì)通知的響應(yīng)，Update()調(diào)用Subject對(duì)象的getStatus()獲取數(shù)據(jù)，然后更新自身。當(dāng)不需要繼續(xù)觀察時(shí)，ConcreteObserver對(duì)象調(diào)用Subject對(duì)象的Detach()方法，其引用被從列表中移除。

       解除目標(biāo)對(duì)具體觀察者的依賴以后，很容易增加新的具體觀察者，因?yàn)椴皇芤蕾嚨姆矫婢涂梢宰杂勺兓?；而目?biāo)也可以獨(dú)立地復(fù)用，因?yàn)闊o(wú)所依賴的方面就可以不受影響。
       以上主要考慮了一個(gè)目標(biāo)有多個(gè)觀察者的情況，我們?cè)O(shè)法解除了目標(biāo)對(duì)具體觀察者的依賴，使具體觀察者的種類和數(shù)目容易改變。有時(shí)候一個(gè)觀察者觀察多個(gè)目標(biāo)也是有意義的，在前面的類圖中，觀察者對(duì)具體目標(biāo)的依賴仍然存在，因此無(wú)法適應(yīng)目標(biāo)方面的變化。怎樣抽象這種依賴呢？使觀察者只知道若干個(gè)目標(biāo)會(huì)向自己發(fā)出通知，而不知道這些目標(biāo)具體是誰(shuí)，可能有多少個(gè)；在目標(biāo)向觀察者發(fā)送通知時(shí)，將一個(gè)自身的引用作為參數(shù)，然后觀察者調(diào)用其抽象方法就可以獲得目標(biāo)狀態(tài)。這就使得觀察者對(duì)目標(biāo)的依賴是抽象的，觀察者對(duì)具體目標(biāo)的依賴被解除了。
       類圖如下：

參考資料：
1.《設(shè)計(jì)模式-可復(fù)用面向?qū)ο筌浖幕A(chǔ)》/Erich Gamma等著，李英軍等譯 機(jī)械工業(yè)出版社
2.《Java與模式》/閻宏 電子工業(yè)出版社
3.  模型-視圖-控制器 ( MSDN > 技術(shù)資源庫(kù) > 體系結(jié)構(gòu) > 使用 Microsoft .NET 的企業(yè)解決方案模式 >第3章 Web 表示模式)
4. 《Java設(shè)計(jì)：對(duì)象，UML和過(guò)程》/Kirk Knoernschild 著，羅英偉等譯 人民郵電出版社
5. 《計(jì)算機(jī)網(wǎng)絡(luò)與因特網(wǎng)》/D.E.Comer 著 徐良賢等譯 機(jī)械工業(yè)出版社
6.《深入解析MFC》/中國(guó)電力出版社
7.《VC技術(shù)內(nèi)幕》第5版 / 希望電子出版社