MVC、MVP、MVVM

時間 2019-11-15

標籤 mvc mvp mvvm 简体版

原文原文鏈接

1 簡介

　　演變：MVC ——> MVP ——> MVVM

　　三者的目的都是分離關注，使得UI更容易變換（從Winform變爲Webform），使得UI更容易進行單元測試。javascript

　　MVC模式（Model-View-Controller）是軟件工程中的一種軟件架構模式，把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。html

　　MVC模式的目的是實現一種動態的程式設計，使後續對程序的修改和擴展簡化，而且使程序某一部分的重複利用成爲可能。除此以外，此模式經過對複雜度的簡化，使程序結構更加直觀。軟件系統經過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員能夠經過自身的專長分組：java

（控制器 Controller）- 負責轉發請求，對請求進行處理。
（視圖 View） - 界面設計人員進行圖形界面設計。
（模型 Model） - 程序員編寫程序應有的功能（實現算法等等）、數據庫專家進行數據管理和數據庫設計(能夠實現具體的功能)。

2 MVC/MVP

　　2.1 MVCnode

　　一、View接受用戶的交互請求程序員

　　二、View將請求轉交給Controllerweb

　　三、Controller操做Model進行數據更新算法

　　四、數據更新以後，Model通知View數據變化數據庫

　　五、View顯示更新以後的數據設計模式

　　View和Controller使用Strategy模式實現，View使用Composite模式，View和Model經過Observer模式同步信息。Controller不知道任何View的細節，一個Controller能被多個View使用。MVC的一個缺點是很難對Controller進行單元測試，Controller操做數據，可是如何從View上斷言這些數據的變化呢？例如，點擊一個View的按鈕，提交一個事件給Controller，Controller修改Model的值。這個值反映到View上是字體和顏色的變化。測試這個Case仍是有點困難的。架構

　　2.2 MVP

　　一、View接受用戶的交互請求

　　二、View將請求轉交給Presenter

　　三、Presenter操做Model進行數據庫更新

　　四、數據更新以後，Model通知Presenter數據發生變化

　　五、Presenter更新View的數據

　　Presenter將Model的變化返回給View。和MVC不一樣的是，Presenter會副作用於View，不像Controller只會被動的接受View的指揮。正常狀況下，發現能夠抽象View，暴露屬性和事件，而後Presenter引用View的抽象。這樣能夠很容易的構造View的Mock對象，提升可單元測試性。在這裏，Presenter的責任變大了，不只要操做數據，並且要更新View。

　　在現實中，MVP的實現會根據View的充、貧血而有一些不一樣，一部分傾向於在View中放置簡單的邏輯，在Presenter放置複雜的邏輯；另外一部分傾向於在presenter中放置所有的邏輯。這兩種分別被稱爲：Passive View和Superivising Controller。

　　在Passive View中，爲了減小UI組件的行爲，使用Controller不只控制用戶事件的響應，並且將結果更新到View上。能夠集中測試Controller，減少View出問題的風險。

　　在Superivising Controller中的Controller既處理用戶輸入的響應，又操做View處理View的複雜邏輯。

附註：

　　MVP與MVC有着一個重大的區別：在MVP中View並不直接使用Model，它們之間的通訊是經過Presenter (MVC中的Controller)來進行的，全部的交互都發生在Presenter內部，而在MVC中View會從直接Model中讀取數據而不是經過 Controller。

MVC存在的問題：

　　在MVC裏，View是能夠直接訪問Model的！從而，View裏會包含Model信息，不可避免的還要包括一些業務邏輯。在MVC模型裏，更關注的Model的不變，而同時有多個對Model的不一樣顯示，及View。因此，在MVC模型裏，Model不依賴於View，可是View是依賴於Model的。不只如此，由於有一些業務邏輯在View裏實現了，致使要更改View也是比較困難的，至少那些業務邏輯是沒法重用的。

MVP的解決方式：

　　在MVP裏，Presenter徹底把Model和View進行了分離，主要的程序邏輯在Presenter裏實現。

　　並且，Presenter與具體的View是沒有直接關聯的，而是經過定義好的接口進行交互，從而使得在變動View時候能夠保持Presenter的不變，即重用！

　　不只如此，咱們還能夠編寫測試用的View，模擬用戶的各類操做，從而實現對Presenter的測試--而不須要使用自動化的測試工具。

　　咱們甚至能夠在Model和View都沒有完成時候，就能夠經過編寫Mock Object（即實現了Model和View的接口，但沒有具體的內容的）來測試Presenter的邏輯。

　　在MVP裏，應用程序的邏輯主要在Presenter來實現，其中的View是很薄的一層。所以就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發Presenter。在這個過程當中，View是很簡單的，可以把信息顯示清楚就能夠了。在後面，根據須要再隨便更改View，而對Presenter沒有任何的影響了。若是要實現的UI比較複雜，並且相關的顯示邏輯還跟Model有關係，就能夠在View和Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免二者之間的關聯。而同時，由於Adapter實現了View的接口，從而能夠保證與Presenter之間接口的不變。這樣就能夠保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。在MVP模式裏，View只應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的內容，除此就不該該有更多的內容，毫不允許直接訪問Model--這就是與MVC很大的不一樣之處。

MVP的優勢：

模型與視圖徹底分離，咱們能夠修改視圖而不影響模型
能夠更高效地使用模型，由於全部的交互都發生在一個地方——Presenter內部
咱們能夠將一個Presenter用於多個視圖，而不須要改變Presenter的邏輯。這個特性很是的有用，由於視圖的變化老是比模型的變化頻繁。
若是咱們把邏輯放在Presenter中，那麼咱們就能夠脫離用戶接口來測試這些邏輯（單元測試）

MVP的缺點：

　　因爲對視圖的渲染放在了Presenter中，因此視圖和Presenter的交互會過於頻繁。還有一點須要明白，若是Presenter過多地渲染了視圖，每每會使得它與特定的視圖的聯繫過於緊密。一旦視圖須要變動，那麼Presenter也須要變動了。好比說，本來用來呈現Html的Presenter如今也須要用於呈現Pdf了，那麼視圖頗有可能也須要變動。

3 M-V-VM

　　由於WPF技術出現，從而使MVP設計模式有所改進，MVVM 模式即是使用的是數據綁定基礎架構。它們能夠輕鬆構建UI的必要元素。

　　MVVM是在原有領域Model的基礎上添加一個ViewModel，這個ViewModel除了正常的屬性意外，還包括一些供View顯示用的屬性。例如在經典的MVP中，View有一個屬性IsCheck，須要在Presenter中設置View的IsCheck值。可是在MVVM中的Presenter也會有一個IsCheck屬性來同步View的IsCheck屬性，可能會用到Observer模式同步IsCheck的值。在MVVM中，Presenter被更名爲ViewModel，就演變成了你看到的MVVM。在支持雙向綁定的平臺，MVVM更受歡迎。例如：微軟的WPF和Silverlight。

MVVM的優勢：

低耦合。視圖（View）能夠獨立於Model變化和修改，一個ViewModel能夠綁定到不一樣的"View"上，當View變化的時候Model能夠不變，當Model變化的時候View也能夠不變。
可重用性。你能夠把一些視圖邏輯放在一個ViewModel裏面，讓不少view重用這段視圖邏輯。
獨立開發。開發人員能夠專一於業務邏輯和數據的開發（ViewModel），設計人員能夠專一於頁面設計，使用Expression Blend能夠很容易設計界面並生成xaml代碼。
可測試。界面素來是比較難於測試的，而如今測試能夠針對ViewModel來寫。