• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            依舊的博客

            技術學習

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              17 Posts :: 1 Stories :: 2 Comments :: 0 Trackbacks

            MVC(Model-View-Controller)模式的基本思想是數(shù)據(jù),顯示和處理相分離。模型(Model)負責數(shù)據(jù)管理,視圖(View)負責數(shù)據(jù)顯示,控制器(Controller)負責業(yè)務邏輯和響應策略。

            從MVC的形成過程來看,最初只有模型和視圖兩個元素。模型封裝了數(shù)據(jù)并提供操作接口,視圖用來表現(xiàn)數(shù)據(jù)和接收用戶請求。模型是獨立的,而視圖依賴于模型:從模型獲取數(shù)據(jù)進行顯示;向模型發(fā)送用戶請求,并根據(jù)返回結果刷新自己。

            需要用多個視圖表現(xiàn)同一模型時,情況發(fā)生了變化:一個視圖修改數(shù)據(jù)以后,不但本身要刷新,其他所有視圖也要刷新。如果由該視圖通知其他視圖,它就需要知道其他所有視圖,由于每個視圖都可能發(fā)出修改,每個視圖都要知道其他所有視圖,這種關聯(lián)過于復雜,不但難以維護,而且不便于增加新的視圖。如果讓模型通知所有視圖更新,可能會影響模型的獨立性。用觀察者(Observer)模式可以解決上述矛盾,從而實現(xiàn):由模型通知視圖,而模型不依賴于具體的視圖,具體視圖之間相互獨立。

            視圖是用戶請求的接收者,但不宜作為請求的處理者。因為界面是易變的,如果業(yè)務代碼和界面代碼放在一起,頻繁的界面修改可能會破壞比較穩(wěn)定的業(yè)務代碼。將業(yè)務邏輯分離出來,由一個控制器負責,就是為了避免這種干擾。

            模型,視圖和控制器的基本協(xié)作關系如下圖

            MVC模式協(xié)作圖.gif

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

            MVC模式協(xié)作圖2.gif


            同樣的數(shù)據(jù),可以有不同的顯示和進行各種處理。顯示僅僅是表現(xiàn)數(shù)據(jù),而處理是根據(jù)用戶請求改變數(shù)據(jù)的過程,不但包含業(yè)務邏輯,也要提供響應策略。響應策略由控制器負責,視圖可以使用不同的控制器提供不同的響應方式,這是策略(Strategy)模式的應用。

            此外,MVC還允許視圖嵌套,通過使用組合(Composite)模式,一致地處理組合視圖和普通視圖。

            用多個視圖表現(xiàn)一個模型,在視圖不變的情況下改變響應策略,允許視圖嵌套,這是MVC的三個主要特性。在內(nèi)部結構上,MVC的主要關系是由觀察者模式,策略模式和組合模式給出的。由觀察者模式確定的模型視圖關系是其中最為重要的。

            MVC模式有許多變體。前述結構中,由模型通知視圖刷新,稱為主動MVC;如果由控制器更新模型以后通知視圖,稱為被動MVC結構。在許多應用中,沒有明顯的控制器角色,也沒有視圖嵌套。可見根據(jù)實際需要,構成MVC的三個模式上都可能出現(xiàn)變化。Web瀏覽器就是被動MVC結構的一個實例。
            “瀏覽器是一個交互程序,從概念上講,它是由一組客戶、一組解釋器與一個管理它們的控制器所組成。控制器形成了瀏覽器的中心部件,它解釋鼠標點擊與鍵盤輸入,并且調(diào)用其他組件來執(zhí)行用戶指定的操作。例如,當用戶鍵入一個URL或者點擊一個超文本引用時,控制器調(diào)用一個客戶從所需文檔所在的遠程服務器上取回該文檔,并且調(diào)用解釋器向用戶顯示該文檔。每個瀏覽器必須包含一個HTML解釋器來顯示文檔,其他解釋器是可選的。HTML解釋器的輸入由符合HTML語法的文檔所組成,輸出由位于用戶顯示器上的格式版本文檔所組成。解釋器通過將HTML規(guī)則轉換成適合用戶顯示硬件的命令來處理版面細節(jié)。HTML解釋器一個最重要的功能是包含可選項。解釋器必須存儲關于顯示器上位置之間關系的信息和HTML文檔中被瞄定的項。當用戶用鼠標選定了一個項,瀏覽器通過當前的光標位置和存儲的位置信息來決定哪個項被用戶選定。”(參考資料5)


            MFC的文檔/視圖結構(Document/View architecture)是MVC模式的一種變體,下面討論它是怎樣實現(xiàn)的。

            文檔/視圖結構沒有體現(xiàn)業(yè)務邏輯和視圖的分離,但是將響應策略和視圖區(qū)分開來。它主要包含四種對象:

            1. 文檔
            2. 視圖
            3. 視圖框架窗口
            4. 文檔模板

            這里的視圖框架窗口定義了視圖對用戶輸入的響應方式,而文檔模板用來管理前三種對象的組合。文檔,視圖,視圖框架窗口三者是對應的,從而構成一個三元組。一個應用程序可能需要多個這樣的三元組,以實現(xiàn)文檔的多視圖,所以引入文檔模板來表示該三元組。因為程序中可能使用多個文檔模板,MFC用一個文檔管理者對象來管理它們。

            在MFC中,應用程序和主框架窗口是用來封裝底層機制的對象,文檔,視圖,視圖框架窗口和文檔模板是用來構架文檔/視圖結構的對象。應用程序通過文檔管理者來使用文檔/視圖結構。

            如果要給文檔增加一種視圖,只需要增加一個文檔模板;如果要改變一種視圖的響應策略,只要改變對應文檔模板中的視圖框架窗口。

            <未完待續(xù)>


            參考資料:

            1.《設計模式-可復用面向對象軟件的基礎》/Erich Gamma等著,李英軍等譯 機械工業(yè)出版社
            2.《Java與模式》/閻宏 電子工業(yè)出版社
            3.  模型-視圖-控制器 ( MSDN > 技術資源庫 > 體系結構 > 使用 Microsoft .NET 的企業(yè)解決方案模式 >第3章 Web 表示模式)
            4. 《Java設計:對象,UML和過程》/Kirk Knoernschild 著,羅英偉等譯 人民郵電出版社
            5. 《計算機網(wǎng)絡與因特網(wǎng)》/D.E.Comer 著 徐良賢等譯 機械工業(yè)出版社
            6.《深入解析MFC》/中國電力出版社
            7.《VC技術內(nèi)幕》第5版 / 希望電子出版社

            posted on 2006-08-06 10:05 依舊的博客 閱讀(3060) 評論(0)  編輯 收藏 引用
            久久只这里是精品66| 久久综合欧美成人| 国产成人无码精品久久久性色 | 一本色道久久88加勒比—综合| 精品久久久久中文字幕日本| 精品多毛少妇人妻AV免费久久 | 久久国产成人| 亚洲精品乱码久久久久久久久久久久| 国产成人久久精品激情 | 久久996热精品xxxx| 亚洲中文字幕久久精品无码APP | 亚洲国产精品久久久久婷婷老年 | 人妻无码αv中文字幕久久琪琪布| 77777亚洲午夜久久多喷| 老司机午夜网站国内精品久久久久久久久| 亚洲国产精品18久久久久久| 久久国产成人亚洲精品影院| 久久精品国产亚洲AV无码麻豆 | 国产精品久久久久AV福利动漫 | 亚洲欧美成人久久综合中文网 | 伊人色综合久久天天人手人婷| 韩国三级中文字幕hd久久精品| 99久久99这里只有免费的精品| 少妇被又大又粗又爽毛片久久黑人 | 中文字幕久久精品无码| 思思久久99热免费精品6| 精品久久久久久| 国产精品久久国产精品99盘| 久久久噜噜噜www成人网| 狠狠色丁香久久婷婷综合图片| 久久久久亚洲AV成人网人人网站| 一级做a爰片久久毛片人呢| 久久本道伊人久久| 99国产精品久久久久久久成人热| 欧洲成人午夜精品无码区久久 | 国产精品久久亚洲不卡动漫| 亚洲欧美日韩中文久久| 久久国产高潮流白浆免费观看| 久久香蕉国产线看观看精品yw| 久久精品无码专区免费东京热| 久久成人国产精品|