MVC、MVP和MVVM都是為了解決界面呈現(xiàn)和邏輯代碼分離而出現(xiàn)的開發(fā)模式。MVP和MVVM都是在MVC的基礎上演化而來。

一、MVC模式

MVC是Model-View-Controller的簡稱。Model：模型層，負責處理數(shù)據(jù)的加載或者存儲。View：視圖層，負責界面數(shù)據(jù)的展示，與用戶進行交互。Controller：控制器層，負責邏輯業(yè)務的處理。

MVC關系模型圖

在MVC里，View是可以直接訪問Model的。從而，View里會包含Model信息，不可避免的還要包括一些業(yè)務邏輯。 在MVC模型里，更關注的Model的不變，而同時有多個對Model的不同顯示，及View。所以，在MVC模型里，Model不依賴于View，但是View是依賴于Model的。不僅如此，因為有一些業(yè)務邏輯在View里實現(xiàn)了，導致要更改View也是比較困難的，至少那些業(yè)務邏輯是無法重用的。
優(yōu)點：
1.耦合性低
2.重用性高
3.生命周期成本低
4.部署快
5.可維護性高
6.有利軟件工程化管理

缺點：
沒有明確的定義
不適合大型，中等規(guī)模的應用程序
增加系統(tǒng)結構和實現(xiàn)的復雜性
視圖與控制器間的過于緊密的連接
視圖對模型數(shù)據(jù)的低效率訪問
一般高級的界面工具或構造器不支持模式

二、MVP模式

View: 對于View層也是視圖層，在View層中只負責對數(shù)據(jù)的展示，提供友好的界面與用戶進行交互。在Android開發(fā)中通常將Activity或者Fragment作為View層。
Model: 對于Model層也是數(shù)據(jù)層。它區(qū)別于MVC架構中的Model，在這里不僅僅只是數(shù)據(jù)模型。在MVP架構中Model它負責對數(shù)據(jù)的存取操作，例如對數(shù)據(jù)庫的讀寫，網(wǎng)絡的數(shù)據(jù)的請求等。
Presenter:對于Presenter層他是連接View層與Model層的橋梁并對業(yè)務邏輯進行處理。在MVP架構中Model與View無法直接進行交互。所以在Presenter層它會從Model層獲得所需要的數(shù)據(jù)，進行一些適當?shù)奶幚砗蠼挥蒝iew層進行顯示。這樣通過Presenter將View與Model進行隔離，使得View和Model之間不存在耦合，同時也將業(yè)務邏輯從View中抽離。

MVP關系模型圖

在MVP架構中將這三層分別抽象到各自的接口當中。通過接口將層次之間進行隔離，而Presenter對View和Model的相互依賴也是依賴于各自的接口。這點符合了接口隔離原則，也正是面向接口編程。在Presenter層中包含了一個View接口，并且依賴于Model接口，從而將Model層與View層聯(lián)系在一起。而對于View層會持有一個Presenter成員變量并且只保留對Presenter接口的調(diào)用，具體業(yè)務邏輯全部交由Presenter接口實現(xiàn)類中處理。

MVC與MVP兩種模式的主要區(qū)別： （最主要區(qū)別）View與Model并不直接交互，而是通過與Presenter交互來與Model間接交互。而在MVC中View可以與Model直接交互 通常View與Presenter是一對一的，但復雜的View可能綁定多個Presenter來處理邏輯。而Controller是基于行為的，并且可以被多個View共享，Controller可以負責決定顯示哪個View Presenter與View的交互是通過接口來進行的，更有利于添加單元測試。

優(yōu)點：
1、模型與視圖完全分離，我們可以修改視圖而不影響模型；
2、可以更高效地使用模型，因為所有的交互都發(fā)生在一個地方——Presenter內(nèi)部；
3、我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。
4、邏輯結構更加清晰，解決Activity代碼臃腫問題

三、MVVM模式

MVVM 模式，即指 Model-View-ViewModel。它將 View 的狀態(tài)和行為完全抽象化，把邏輯與界面的控制完全交給 ViewModel 處理

MVVM關系模型圖

• View：主要進行視圖控件的一些初始設置，不應該有任何的數(shù)據(jù)邏輯操作。
• Model：定義實體類，以及獲取業(yè)務數(shù)據(jù)模型，比如通過數(shù)據(jù)庫或者網(wǎng)絡來操作數(shù)據(jù)等。
• ViewModel：作為連接 View 與 Model 的中間橋梁，ViewModel 與 Model 直接交互，處理完業(yè)務邏輯后，通過 DataBinding 將數(shù)據(jù)變化反應到用戶界面上。

優(yōu)點：

• 低耦合度
  在 MVVM 模式中，數(shù)據(jù)處理邏輯是獨立于 UI 層的。ViewModel 只負責提供數(shù)據(jù)和處理數(shù)據(jù)，不會持有 View 層的引用。而 View 層只負責對數(shù)據(jù)變化的監(jiān)聽，不會處理任何跟數(shù)據(jù)相關的邏輯。在 View 層的 UI 發(fā)生變化時，也不需要像 MVP 模式那樣，修改對應接口和方法實現(xiàn)，一般情況下ViewModel 不需要做太多的改動。
• 數(shù)據(jù)驅(qū)動
  MVVM 模式的另外一個特點就是數(shù)據(jù)驅(qū)動。UI 的展現(xiàn)是依賴于數(shù)據(jù)的，數(shù)據(jù)的變化會自然的引發(fā) UI 的變化，而 UI 的改變也會使數(shù)據(jù) Model 進行對應的更新。ViewModel 只需要處理數(shù)據(jù)，而 View 層只需要監(jiān)聽并使用數(shù)據(jù)進行 UI 更新。
• 異步線程更新 Model
  Model 數(shù)據(jù)可以在異步線程中發(fā)生變化，此時調(diào)用者不需要做額外的處理，數(shù)據(jù)綁定框架會將異步線程中數(shù)據(jù)的變化通知到 UI 線程中交給 View 去更新。
• 方便協(xié)作
  View 層和邏輯層幾乎沒有耦合，在團隊協(xié)作的過程中，可以一個人負責 UI，一個人負責數(shù)據(jù)處理。并行開發(fā)，保證開發(fā)進度。
• 易于單元測試
  MVVM 模式比較易于進行單元測試。ViewModel 層只負責處理數(shù)據(jù)，在進行單元測試時，測試不需要構造一個 fragment/Activity/TextView 等等來進行數(shù)據(jù)層的測試。同理 View 層也一樣，只需要輸入指定格式的數(shù)據(jù)即可進行測試，而且兩者相互獨立，不會互相影響。
• 數(shù)據(jù)復用
  ViewModel 層對數(shù)據(jù)的獲取和處理邏輯，尤其是使用 Repository 模式時，獲取數(shù)據(jù)的邏輯完全是可以復用的。開發(fā)者可以在不同的模塊，多次方便的獲取同一份來源的數(shù)據(jù)。同樣的一份數(shù)據(jù)，在版本功能迭代時，邏輯層不需要改變，只需要改變 View 層即可。