MV*模式總結

開發應用程序時，以求更好的管理應用程序的複雜性，基於職責分離的思想對應用程序進行分層：

• view: 管理用戶界面的層次
• Model: 應用程序的數據

MVC

MVC 把應用程序分紅View、Model、Controller層。

• Controller: 進行Model和View之間的協做（路由、輸入預處理）的應用邏輯
• Model： 進行處理業務邏輯（對比Spring MVC 中的Dao層）

MVC的依賴關係

MVC出了把應用程序分紅View、Model層，還額外的加了一個Controller層，它的職責爲進行Model和View之間的協做（路由、輸入預處理等）的應用邏輯（application logic）；Model進行處理業務邏輯。Model、View、Controller三個層次的依賴關係以下：

Controller和View都依賴Model層，Controller和View能夠互相依賴。Controller和View的依賴關係都是爲了把處理用戶行爲觸發的事件處理權交給Controller。

MVC 的調用關係

1. 用戶操做View ，View 把控制權移交給Controller, Controller執行應用程序相關的應用邏輯（對來自View數據進行預處理、決定調用哪一個Model的接口等等）。
2. Controller操做Model，Model執行業務邏輯對數據進行處理。但不會直接操做View，能夠說它是對View無知的。
3. View和Model的同步消息是經過觀察者模式進行，而同步操做是由View本身請求Model的數據而後對視圖進行更新。

MVC 的優缺點

優勢：

• 把業務邏輯和展現邏輯分離，模塊化程度高。且當應用邏輯須要變動的時候，不須要變動業務邏輯和展現邏輯，只須要Controller換成另一個Controller就好了（Swappable Controller）。
• 觀察者模式能夠作到多視圖同時更新。

缺點：

• ontroller測試困難。由於視圖同步操做是由View本身執行，而View只能在有UI的環境下運行。在沒有UI環境下對Controller進行單元測試的時候，應用邏輯正確性是沒法驗證的：Model更新的時候，沒法對View的更新操做進行斷言。
• View沒法組件化。View是強依賴特定的Model的，若是須要把這個View抽出來做爲一個另一個應用程序可複用的組件就困難了。由於不一樣程序的的Domain Model是不同的

MVP

MVP模式是MVC模式的改良。

MVP模式有兩種：

• Passive View
• Supervising Controller

大多數狀況下討論的都是Passive View模式

MVP（Passive View）的依賴關係

MVP模式把MVC模式中的Controller換成了Presenter。MVP層次之間的依賴關係以下：

MVP打破了View原來對於Model的依賴，其他的依賴關係和MVC模式一致。

MVP（Passive View）的調用關係

調用關係以下：

用戶對View的操做都會從View交移給Presenter。Presenter會執行相應的應用程序邏輯，而且對Model進行相應的操做；而這時候Model執行完業務邏輯之後，也是經過觀察者模式把本身變動的消息傳遞出去，可是是傳給Presenter而不是View。Presenter獲取到Model變動的消息之後，經過View提供的接口更新界面。

MVP（Passive View）的優缺點

優勢：

• 便於測試。Presenter對View是經過接口進行，在對Presenter進行不依賴UI環境的單元測試的時候。能夠經過Mock一個View對象，這個對象只須要實現了View的接口便可。而後依賴注入到Presenter中，單元測試的時候就能夠完整的測試Presenter應用邏輯的正確性。
• view 能夠進行組件化。在MVP當中，View不依賴Model。這樣就可讓View從特定的業務場景中脫離出來，能夠說View能夠作到對業務徹底無知。它只須要提供一系列接口提供給上層操做。這樣就能夠作到高度可複用的View組件。

缺點：

• Presenter中除了應用邏輯之外，還有大量的View->Model，Model->View的手動同步邏輯，形成Presenter比較笨重，維護起來會比較困難。

MVP（Supervising Controller）

Passive View模式，該模式下View很是Passive，它幾乎什麼都不知道，Presenter讓它幹什麼它就幹什麼。Supervising Controller模式中，Presenter會把一部分簡單的同步邏輯交給View本身去作，Presenter只負責比較複雜的、高層次的UI操做，因此能夠把它當作一個Supervising Controller

Supervising Controller模式下的依賴和調用關係：

Supervising Controller用得比較少

MVVM

MVVM能夠看做是一種特殊的MVP（Passive View）模式，或者說是對MVP模式的一種改良。

MVVM表明的是Model-View-ViewModel，ViewModel的含義就是 "Model of View"，視圖的模型。它的含義包含了領域模型（Domain Model）和視圖的狀態（State）。
在圖形界面應用程序當中，界面所提供的信息可能不只僅包含應用程序的領域模型。還可能包含一些領域模型不包含的視圖狀態，例如電子表格程序上須要顯示當前排序的狀態是順序的仍是逆序的，而這是Domain Model所不包含的，但也是須要顯示的信息。

能夠簡單把ViewModel理解爲頁面上所顯示內容的數據抽象，和Domain Model不同，ViewModel更適合用來描述View。

MVVM的依賴

MVVM的依賴關係和MVP依賴，只不過是把P換成了VM。

MVVM的調用關係

MVVM的調用關係和MVP同樣。可是，在ViewModel當中會有一個叫Binder，或者是Data-binding engine的東西。之前所有由Presenter負責的View和Model之間數據同步操做交由給Binder處理。你只須要在View的模版語法當中，指令式地聲明View上的顯示的內容是和Model的哪一塊數據綁定的。當ViewModel對進行Model更新的時候，Binder會自動把數據更新到View上去，當用戶對View進行操做（例如表單輸入），Binder也會自動把數據更新到Model上去。這種方式稱爲：Two-way data-binding，雙向數據綁定。能夠簡單而不恰當地理解爲一個模版引擎，可是會根據數據變動實時渲染。

總結: MVVM把View和Model的同步邏輯自動化了。之前Presenter負責的View和Model同步再也不手動地進行操做，而是交由框架所提供的Binder進行負責。只須要告訴Binder，View顯示的數據對應的是Model哪一部分便可。

MVVM 前端框架有： angular、vue.js

MVVM的優缺點

優勢：

1. 提升可維護性。解決了MVP大量的手動View和Model同步的問題，提供雙向綁定機制。提升了代碼的可維護性。
2. 簡化測試。由於同步邏輯是交由Binder作的，View跟着Model同時變動，因此只須要保證Model的正確性，View就正確。大大減小了對View同步更新的測試。

缺點：

1. 過於簡單的圖形界面不適用，或說牛刀殺雞。
2. 對於大型的圖形應用程序，視圖狀態較多，ViewModel的構建和維護的成本都會比較高。
3. 數據綁定的聲明是指令式地寫在View的模版當中的，這些內容是沒辦法去打斷點debug的。

文章轉載自： https://github.com/livoras/bl...