詳解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處理後的數據。

一樣的數據，能夠有不一樣的顯示和進行各類處理。顯示僅僅是表現數據，而處理是根據用戶請求改變數據的過程，不但包含業務邏輯，也要提供響應策略。響應策略由控制器負責，視圖可使用不一樣的控制器提供不一樣的響應方式，這是策略(Strategy)模式的應用。

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

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

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

二、爲何要在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須要精心的計劃，因爲它的內部原理比較複雜，因此須要花費一些時間去思考。同時因爲模型和視圖要嚴格的分離，這樣也給調試應用程序到來了必定的困難。

3.3 MVC 模式能夠分解爲如下設計模式

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

(1)、觀察者模式

(2)、合成模式

(3)、策略模式

4 談談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模式的三層解耦，這樣能夠保持設計乾淨又有彈性。