MVC與設計模式的關係及MVC的實現原理和設計原理

標籤：

1 MVC介紹

眾所周知MVC不是設計模式，是一個比設計模式更大一點的模式，稱作設計模式不合理，應該說MVC它是一種軟體開發架構模式，它包含了很多的設計模式，最為密切是以下三種：Observer (觀察者模式), Composite（組合模式）和Strategy（策略模式）。所以說MVC模式又稱複合模式。MVC(Model-View-Controller) 模式的基本思想是資料，顯示和處理相分離。模型(Model)負責資料管理，視圖(View)負責資料顯示，控制器(Controller)負責商務邏輯和響應策略。

從MVC的形成過程來看，最初只有模型和視圖兩個元素。模型封裝了資料並提供操作介面，視圖用來表現資料和接收使用者請求。模型是獨立的，而視圖依賴於模型：從模型擷取資料進行顯示；向模型發送使用者請求，並根據返回結果重新整理自己。

需要用多個視圖表現同一模型時，情況發生了變化：一個視圖修改資料以後，不但本身要重新整理，其他所有視圖也要重新整理。如果由該視圖通知其他視圖，它就需要知道其他所有視圖，由於每個視圖都可能發出修改，每個視圖都要知道其他所有視圖，這種關聯過於複雜，不但難以維護，而且不便於增加新的視圖。如果讓模型通知所有視圖更新，可能會影響模型的獨立性。用觀察者(Observer)模式 可以解決上述矛盾，從而實現：由模型通知視圖，而模型不依賴於具體的視圖，具體視圖之間相互獨立。

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

模型，視圖和控制器的基本協作關係如

模型在狀態變化的時候，直接通知所有視圖，視圖向模型查詢狀態資料，然後重新整理自身。當使用者發出操作時，視圖把訊息發給控制器，控制器按照商務邏輯進行處理，需要查詢或更新資料時，控制器會調用模型。下面是一個更詳細的
MVC架構把資料處理，程式輸入輸出控制及資料顯示分離開來，並且描述了不同組件的對象間的通訊方式。使得軟體可維護性，可擴充性，靈活性以及封裝性大大提高；MVC(Model-View-Controller)把系統的組成分解為M（模型）、 V（視圖）、C（控制器）三種組件。視圖表示資料在螢幕上的顯示。控制器提供處理過程式控制制，它在模型和視圖之間起串連作用。控制器本身不輸出任何資訊和做任何處理，它只負責把使用者的請求轉成針對Model的操作，和調用相應的視圖來顯示Model處理後的資料。三者之間關係如2.1：

                                                             圖2.1  MVC關係圖
同樣的資料，可以有不同的顯示和進行各種處理。顯示僅僅是表現資料，而處理是根據使用者請求改變資料的過程，不但包含商務邏輯，也要提供響應策略。響應策略由控制器負責，視圖可以使用不同的控制器提供不同的回應程式式，這是策略(Strategy)模式的應用。

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

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

MVC 模式有許多變體。前述結構中，由模型通知視圖重新整理，稱為主動MVC；如果由控制器更新模型以後通知視圖，稱為被動MVC結構。在許多應用中，沒有明顯的控制器角色，也沒有視圖嵌套。可見根據實際需要，構成MVC的三個模式上都可能出現變化。Web瀏覽器就是被動MVC結構的一個執行個體。
" 瀏覽器是一個互動程式，從概念上講，它是由一組客戶、一組解譯器與一個管理它們的控制器所組成。控制器形成了瀏覽器的中心組件，它解釋滑鼠點擊與鍵盤輸入，並且調用其他組件來執行使用者指定的操作。例如，當使用者鍵入一個URL或者點擊一個超文本引用時，控制器調用一個客戶從所需文檔所在的遠程伺服器上取回該文檔，並且調用解譯器向使用者顯示該文檔。每個瀏覽器必須包含一個HTML解譯器來顯示文檔，其他解譯器是可選的。HTML解譯器的輸入由符合HTML文法的文檔所組成，輸出由位於使用者顯示器上的格式版本文檔所組成。解譯器通過將HTML規則轉換成適合使用者顯示硬體的命令來處理版面細節。HTML解譯器一個最重要的功能是包含可選項。解譯器必須儲存關於顯示器上位置之間關係的資訊和HTML文檔中被瞄定的項。當使用者用滑鼠選定了一個項，瀏覽器通過當前的游標位置和儲存的位置資訊來決定哪個項被使用者選定。"

2、為什麼要在Web應用中使用MVC架構

使用者介面邏輯的更改往往比商務邏輯頻繁，尤其是在基於Web的應用程式中。例如，可能添加新的使用者介面頁，或者可能完全打亂現有的頁面配置。對顯示的更改，儘可能地不要影響到資料和商務邏輯。

目前大部分Web應用都是將資料代碼和表示混在一起。經驗比較豐富的開發人員會將資料從展示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。儘管構造MVC應用需要一些額外的工作，但它帶來的好處是無庸質疑的。

2.1 提高代碼重用率

最重要的一點是多個視圖能共用一個模型，無論使用者想要Flash介面或是 WAP 介面；用一個模型就能處理它們。由於已經將資料和商務規則從展示層分開，所以可以最大化的重用代碼。

2.2 提高程式的可維護性

因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變資料層和商務規則 [3]。例如，把資料庫從MySQL移植到Oracle，或者把基於RDBMS資料來源改變到LDAP，只需改變模型即可。一旦正確的實現了模型，不管資料來自哪裡，視圖都會正確的顯示它們。MVC架構的運用，使得程式的三個組件相互對立，大大提高了程式的可維護性。

2.3 有利於團隊開發

在開發過程中，可以更好的分工，更好的協作。有利於開發出高品質的軟體。良好的項 目架構設計，將減少編碼工作量 ：採用MVC結構 + 代碼產生器，是大多數Web應用的理想選擇。部分模型(Model)、和預存程序一般可用工具自動產生。控制(Controller)器比較穩定，一般由於架構師（也可能是有經驗的人）完成；那麼整個項目需要手動編寫代碼的地方就只有視圖(View)了。在這種模式下，個人能力不在特別重要，只要懂點文法基礎的人都可以編寫，無論項目成員寫出什麼樣的代碼，都在專案管理者的可控範圍內。即使項目中途換人，也不會有太大問題。在個人能力參差不齊的團隊開發中，採用MVC開發是非常理想的。

3 MVC架構的優點及不足3.1 MVC的優點

MVC的優點體現在以下幾個方面：

（1） 有利於團隊開發分工協作和品質控制，降低開發成本。

（2） 可以為一個模型在運行時同時建立和使用多個視圖。變化-傳播機制可以確保所有相關的視圖及時得到模型資料變化，從而使所有關聯的視圖和控制器做到行為同步。

（3） 視圖與控制器的可接插性，允許更換視圖和控制器對象，而且可以根據需求動態開啟或關閉、甚至在運行期間進行對象替換。

（4） 模型的可移植性。因為模型是獨立於視圖的，所以可以把一個模型獨立地移植到新的平台工作。需要做的只是在新平台上對視圖和控制器進行新的修改。

（5） 潛在的架構結構。可以基於此模型建立應用程式架構，不僅僅是用在設計介面的設計中。

3.2 MVC的缺點

MVC的不足體現在以下幾個方面：

（1）增加了系統結構和實現的複雜性。對於簡單的介面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。

（2）視圖對模型資料的訪問效率低。視圖可能需要多次調用Model才能獲得足夠的顯示資料。

（3）完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。同時由於模型和視圖要嚴格的分離，這樣也給調試應用程式到來了一定的困難。

MVC 模式可以分解為以下設計模式

在GOF書的 Introduction中，有一小節是"Design Patterns in Smalltalk MVC"即介紹在MVC模式裡用到的設計模式。它大概向我們傳達了這樣的資訊：合成模式+策略模式+觀察者模式約等於MVC模式（當然MVC模式要多一些東西）。也就是說它在大部分情況下是下面幾個模式：

1、觀察者模式

類圖結構在Gof裡的表示如下：

2、合成模式
類圖結構在Gof裡的表示如下： 

3、策略模式

類圖結構在Gof裡的表示如下：

談 談 MVC 架構模式中的三個角色  

• Model （模型端）

Mod封裝的是資料來源和所有基於對這些資料的操作。在一個組件中，Model往往表示組件的狀態和操作這些狀態的方法，往往是一系列的公開方法。通過這些公開方法，便可以取得模型端的所有功能。
 
在這些公開方法中，有些是取值方法，讓系統其他部分可以得到模型端的內部狀態參數，其他的改值方法則允許外部修改模型端的內部狀態。模型端還必須有方法登記視圖，以便在模型端的內部狀態發生變化時，可以通知視圖端。我們可以自己定義一個Subject介面來提供登記和通知視圖所需的介面或者繼承 Java.util.Observable類，讓父類完成這件事。

• 多個 View( 視圖端 )

View封裝的是對資料來源Model的一種顯示。一個模型可以由多個視圖，並且可以在需要的時候動態地登記上所需的視圖。而一個視圖理論上也可以同不同的模型關聯起來。
 
在前言裡提到了，MVC模式用到了合成模式，這是因為在視圖端裡，視圖可以嵌套，比如說在一個JFrame組件裡面，可以有菜單組件，很多按鈕組件等。

• 多個 Controller( 控制器端 )

封裝的是外界作用於模型的操作。通常，這些操作會轉寄到模型上，並調用模型中相應的一個或者多個方法（這個方法就是前面在介紹模型的時候說的改值方法）。一般Controller在Model和View之間起到了溝通的作用，處理使用者在View上的輸入，並轉寄給Model來更改其狀態值。這樣 Model和View兩者之間可以做到鬆散耦合，甚至可以彼此不知道對方，而由Controller串連起這兩個部分。也在前言裡提到，MVC用到了策略模式，這是因為View用一個特定的Controller的執行個體來實現一個特定的響應策略，更換不同的Controller，可以改變View對使用者輸入的響應。

MVC (Model-View-Controller) : 模型利用"觀察者"讓控制器和視圖可以隨最新的狀態改變而更新。另一方面，視圖和控制器則實現了"策略模式"。控制器是視圖的行為; 視圖內部使用"組合模"式來管理顯示組件。

以下的MVC解釋圖很好的標示了這種模式：

• 模型使用觀察者模式，以便觀察者更新，同時保持兩者之間的解耦。
• 控制器是視圖的策略，視圖可以使用不同的控制器實現，得到不同的行為。
• 視圖使用組合模式實現使用者介面，使用者介面通常組合了嵌套的組件，像面板、架構和按鈕。
• 這些模式攜手合作，把MVC模式的三層解耦，這樣可以保持設計乾淨又有彈性。

MVC與設計模式的關係及MVC的實現原理和設計原理