MVC、MVP、MVVM 的差異

MVC、MVP、MVVM架構的由來

軟體科技發展的早期,需要使用到軟體來解決的問題並不多,軟體的結構相當的簡單,像是去資料庫撈個100筆資料、顯示數字等等並不需要多少程式碼的運作,幾千或者幾百行就能完成一套軟體,當時並沒有太多軟體工程的概念,所以這個時期的軟體工程師們經常會把所有的程式碼寫在一起。

舉例來說,按下一個按鈕,顯示查詢的資料,程式碼可能會長這樣:

<p id="data"></p>                                      //顯示資料的地方
<Input id="input"></Input>                             //輸入查詢條件
<button id="button" onclick="buttonClick()"></button>  //查詢按鈕

void function buttonClick(){                           //查詢按鈕的函式
     var getInput = document.getelementbyid("input");  //取得查詢條件
     var connection = mysql.create({                   //登入資料庫,建立連線
					host:"IP",
					user:"ID",
					password:"PW",
					database:"db"
					}); 
		 con.connect(function(err) {                       //取得資料,並顯示到視圖上
				  con.query("SELECT * FROM input", function (err, result, fields) {
			    document.getelementbyid("input").innerHTML = result;
				  });
			});
}

這個例子只有不到20行,但是裡面包含了顯示畫面的html語法、畫面上按鈕的function、資料庫操作的SQL,短短的幾行倒還好理解,一旦功能增加程式碼擴展成了幾千幾萬行,就成為了任何軟體工程師的噩夢。

隨著一個軟體的逐漸發展成長,各種新功能不斷的增加,程式碼會變得越來越複雜,如果持續按照上面的例子把所有的程式碼寫在一起,最後會變成一長串沒有人有能力去維護的程式碼,需要修改功能的時候,找一行程式碼找半天,更慘的若是許多的功能彼此之間有相互關係、高耦合的情況下,會發生改了A功能,B功能就失效,A、B解決了換C功能出問題,C功能繼續往後帶出一連串問題。不僅如此,功能的重複開發也經常發生。

因此,為了避免這些問題,軟體工程師在寫程式的時候,開始有意識地對程式碼做出分類,把UI的部分放在一起,把資料處理的部分放在一起,讓程式碼變得更好維護、更加簡潔,這就是MVC的雛形。

接著1978年挪威的計算機科學家Trygve Reenskaug提出了MVC的架構,讓這種架構有了清楚的定義,隨後在MVC流行起來之後,也演變出了MVP、MVVM以及許多不同的軟體架構模板。

什麼是MVC?

MVC是Model-View-Control的簡稱,主要由3個部分組成,視圖(View)、模型(Model)、控制器(Controller)。

圖片來源:MDN

3個部分各自有自己的工作:

視圖(View):使用者所看到的圖形視圖,視圖一般都會有觸發控制器的部件,使用者則是利用這些部件觸發控制器來取得資料。

模型(Model):負責處理內部的業務邏輯,像是資料庫存取、演算法、資料創建等等,業務處理完後會直接傳輸數據給視圖,通知視圖更新。

控制器(Controller):溝通視圖以及模型之間的橋樑,接收視圖的行為,產生命令通知模型處理業務。

加入使用者後的行為模式圖,會像下面這張圖:

圖片來源:Wiki

MVC的優點

  • 針對多數軟體架構問題的解決方案。
  • 可以在基本架構的基礎上針對不同情境做出變化。

MVC的缺點

  • 不適合大量視圖的設計。
  • 不是所有情況的最優解。

MVC適合的場合

  • 各種Client-Server架構。

什麼是MVP?

MVP是Model-View-Presenter的簡稱,主要由3個部分組成,視圖(View)、模型(Model)、表示器(Presenter)。

圖片來源:Wiki

MVP是MVC的變體,與MVC不同的是,MVC的控制器在對模型進行更新後,模型的數據是直接提供給視圖去顯示,而MVP的做法是模型回傳更新的資料給表示器,再由表示器提供給視圖顯示,視圖與模型之間沒有直接的聯繫。

表示器(Presenter):表示器扮演了,接收視圖的操作轉換成模型的更新命令並通知模型,再接收模型回傳的資料轉換成視圖的顯示數據並提供給視圖顯示。

這種設計的方法目的主要是為了方便進行單元測試(Unit Test)並且減少耦合。在單元測試的概念中,測試對象是獨立或者是由下而上的整合單元,而MVC的架構中,三者之間形成了一個循環,如果要對任一部分進行單元測試,都會和另外兩個部分有牽扯,例如:對控制器進行單元測試,測試控制器命令模型更新,但是確認測試結果時,卻要到視圖去看。

MVP的設計改善了這個問題,表示器進行單元測試時,表示器自己就能夠回傳結果確認。

MVP的優點

  • 相對MVC獨立的架構
  • 分工更加容易

MVP的缺點

  • 視圖高度依賴表示器的操作,因此當建立大量視圖時,表示器的複雜程度就會提升。

MVP適合的場合

  • 網頁開發

什麼是MVVM?

MVVM是Model-View-ViewModel的簡稱,Model與View沒有變化,只是把中間的部分換成了視圖模型(ViewModel)。

圖片來源:Wiki

視圖與模型與MVP是一樣完全的分離的,差別在於視圖模型的定位是更接近模型的形式,並且與視圖可以完全分開,而表示器則是與視圖還有一定程度上的耦合,因為MVP的設計上視圖相對被動甚至是完全被動,這代表了視圖的變化多半都是表示器在控制。

視圖模型(ViewModel):視圖與視圖模型藉由資料繫結(DataBinding)綁定後,可以進行資料的傳遞,接收視圖的命令操作模型,並將模型的資料轉化成適合進行繫結的格式讓視圖能夠順利綁定。

視圖模型與視圖之間的互動是透過資料繫結(DataBinding)成立的,資料繫結需要處理的只有資料資訊,也就是說只要繫結的結構是正確的,不管視圖做出怎樣的更動,都不會影響到資料的傳遞。這種設計改善了MVP設計上表示器與視圖之間的依賴性,讓兩者之間更加的獨立。

MVVM的優點

  • 獨立的架構
  • 分工更加容易
  • 單元測試更容易

MVVM的缺點

  • 佔據較多的資源

MVVM適合的場合

  • 頻繁更動的視圖設計
  • 適合需要使用大量視圖的設計
  • Android應用軟體開發

差異比對


MVCMVPMVVM
視圖複雜度
視圖更動難度中等中等容易
獨立性最差中等最好
單元測試難易度最難中等最容易
整合測試難易度中等最容易最難
更動設計難度最難中等最容易
資源使用程度中等中等
程式碼數量中等

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

回到頂端