MV*的描述

MVC的調用關係

用戶的對View操做之後，View捕獲到這個操做，會把處理的權利交移給Controller（Pass calls）；Controller接着會執行相關的業務邏輯，這些業務邏輯可能須要對Model進行相應的操做；當Model變動了之後，會經過觀察者模式（Observer Pattern）通知View；View經過觀察者模式收到Model變動的消息之後，會向Model請求最新的數據，而後從新更新界面。

優勢：

1. 把業務邏輯所有分離到Controller中，模塊化程度高。當業務邏輯變動的時候，不須要變動View和Model，只須要Controller換成另一個Controller就好了（Swappable Controller）。
2. 觀察者模式能夠作到多視圖同時更新。

缺點：

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

MVP（Passive View）的調用關係

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

關鍵點：

1. View再也不負責同步的邏輯，而是由Presenter負責。Presenter中既有業務邏輯也有同步邏輯。
2. View須要提供操做界面的接口給Presenter進行調用。（關鍵）

對比在MVC中，Controller是不能操做View的，View也沒有提供相應的接口；而在MVP當中，Presenter能夠操做View，View須要提供一組對界面操做的接口給Presenter進行調用；Model仍然經過事件廣播本身的變動，但由Presenter監聽而不是View。

優勢：

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

缺點：

1. Presenter中除了業務邏輯之外，還有大量的View->Model，Model->View的手動同步邏輯，形成Presenter比較笨重，維護起來��比較困難。

MVP（Supervising Controller）

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

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哪一部分便可。

優勢：

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

缺點：

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