MVC、MVP、MVVM為不同的劃分代碼結(jié)構(gòu)的方式，結(jié)構(gòu)依次變得復(fù)雜。

筆者認為主要是為了解決頁面刷新和業(yè)務(wù)邏輯放在那些類中的問題。iOS及Android只有Controller和View用于輔助與顯示的系統(tǒng)類，數(shù)據(jù)層沒有對應(yīng)系統(tǒng)類，所以導(dǎo)致組織代碼結(jié)構(gòu)讓人感到困惑，為此特意研究當下比較流行的模式，加以總結(jié)。

解釋名詞：
界面刷新：只更新界面，不加工數(shù)據(jù)；
業(yè)務(wù)邏輯：只對數(shù)據(jù)進行加工，不包含頁面刷新；
數(shù)據(jù)層：包含Dao（數(shù)據(jù)獲取）和Model（數(shù)據(jù)層實體類）；
回調(diào)：沒有應(yīng)用關(guān)系類A調(diào)用類B方法的觸發(fā)方式，具體可以用定義接口（Java），代理（iOS），CallBack等。

進入正題：

一、MVC

M模型：數(shù)據(jù)層，獲取數(shù)據(jù)，代碼層面包含Dao和數(shù)據(jù)層實體（有別于視圖層實體，因為可能網(wǎng)絡(luò)獲取到的數(shù)據(jù)不一定符合視圖的顯示，如兩次網(wǎng)絡(luò)請求后才能顯示某個視圖，此時要經(jīng)過轉(zhuǎn)換，封裝為新的視圖層實體）；
V視圖：View；
C控制器：控制器，膠水代碼，接收View的事件，觸發(fā)數(shù)據(jù)層事件請求，業(yè)務(wù)邏輯處理，代碼對應(yīng)類為ViewController（VC）或Activity。

代碼之間包含關(guān)系：
包含關(guān)系（直接調(diào)用方法）：C控制器 包含 V視圖；C控制器 包含 M模型
反向回調(diào)關(guān)系（沒有應(yīng)用，間接調(diào)用）：V視圖發(fā)送消息（觸摸事件等）給C控制器；M模型 回調(diào)（異步網(wǎng)絡(luò)請求完畢） C控制器

流程：（->方法調(diào)用 -->回調(diào)）
button點擊事件的觸發(fā)：View --> VC
獲取用戶信息事件的觸發(fā)：VC →Model
異步用戶數(shù)據(jù)完成：Model --> VC
綁定用戶信息到View：VC →View

總結(jié):
具有一定的分層，model徹底解耦，controller和view并沒有解耦
層與層之間的交互盡量使用回調(diào)或者去使用消息機制去完成，盡量避免直接持有
controller和view在android中無法做到徹底分離，但在代碼邏輯層面一定要分清
業(yè)務(wù)邏輯被放置在model層，能夠更好的復(fù)用和修改增加業(yè)務(wù)

問題：
1、model徹底解耦，但controller和view并沒有解耦，界面刷新應(yīng)該放在View層還是Controller中，不明確。
一般，簡單界面，controller中直接包含了View；復(fù)雜界面，生成View類。加劇了View和Controller的界限混亂。
2、Controller中包含事件傳遞，回調(diào)處理，業(yè)務(wù)邏輯，導(dǎo)致Controller臃腫。
為解決MVC的問題，導(dǎo)致MVP模式產(chǎn)生。

二、MVP

M模型：數(shù)據(jù)層
V視圖：View和ViewController（VC）或Activity
Persenter：比MVC模式，抽象出Persenter類，用于處理業(yè)務(wù)邏輯控制器，膠水代碼（鏈接M和V）

代碼之間包含關(guān)系：
包含關(guān)系（直接調(diào)用方法）：VC 包含 View；VC 包含 Persenter；Persenter 包含 M模型
反向回調(diào)關(guān)系（沒有應(yīng)用，間接調(diào)用）：V視圖發(fā)送消息（觸摸事件等）給VC；Persenter 回調(diào) VC；M模型 回調(diào)（異步網(wǎng)絡(luò)請求完畢）Persenter

流程：（->方法調(diào)用 -->回調(diào)）
button點擊事件的觸發(fā)：View-->VC
獲取用戶信息事件的觸發(fā)：VC-> Persenter
Persenter傳遞事件：Persenter-> Model
異步用戶數(shù)據(jù)完成：Model--> Persenter
Persenter回傳：Persenter->VC
綁定用戶信息到View：VC→View
解析：接收觸摸事件；然后觸發(fā)persenter方法，persenter觸發(fā)model層方法，如果是異步（網(wǎng)絡(luò)請求），事件處理完畢，再通過回調(diào)層層上傳數(shù)據(jù)，（persenter可能會要封裝網(wǎng)絡(luò)model為視圖要顯示model的轉(zhuǎn)換），最后vc接收到視圖用的數(shù)據(jù)（可能經(jīng)過persenter轉(zhuǎn)換的數(shù)據(jù)），顯示或刷新數(shù)據(jù)）

總結(jié)：
把VC劃分到View層，解決VC責任不清晰問題，VC用于刷新視圖、接收觸摸事件

問題：
1、業(yè)務(wù)復(fù)雜時，回調(diào)復(fù)雜，不易維護（mvvm可以解決）
2、persenter也會臃腫，因為維護正向的方法調(diào)用，還要維護反向的回調(diào)（mvvm可以解決反向回調(diào)）
為解決上述回調(diào)問題，產(chǎn)生了MVVM模式。

三、MVVM

主要區(qū)別于MVP是視圖和視圖數(shù)據(jù)雙向綁定。將Persenter改為ViewModel。

ViewModel ：
1、處理業(yè)務(wù)邏輯，膠水代碼（同Persenter）；
2、創(chuàng)建關(guān)聯(lián)，將model和view綁定起來,如此之后，我們model的更改，通過viewmodel反饋給view,從而自動刷新界面。（不用再有回調(diào)了）具體使用監(jiān)聽，完成此功能。

好處：解決了mvp的回調(diào)問題

問題：
有問題不好排查，因為是雙向綁定，可能是view的問題，也可能是viewmodel中業(yè)務(wù)的問題

四、幾種模式如何選擇

1，簡單項目，都可以；
2、展示數(shù)據(jù)，交互多：MVVM；
3、業(yè)務(wù)型，交互不多：MVP，MVVM。

參考：https://blog.csdn.net/singwhatiwanna/article/details/80904132