一、MVP模式圖示

MVP 模式將 MVC中的controller 改名為 Presenter，同時改變了通信方向。

特點 :

(1)各部分之間的通信，都是雙向的。

(2)View 與 Model 不發(fā)生聯(lián)系，都通過 Presenter 傳遞。

(3) View 非常薄，不部署任何業(yè)務(wù)邏輯，稱為”被動視圖”（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那里。

M：model層

V:? 視圖層

P:? 協(xié)議層（protocol）

二、MVP在iOS中的運用

首先，MVP基于面向協(xié)議(protocol)的設(shè)計模式。這就意味在工程里面，你需要定義多個協(xié)議文件，但是，我們都知道定制一個協(xié)議，可能會遵循一些屬性或者可選實現(xiàn)必選實現(xiàn)的方法，當(dāng)P層（controller）遵循這個協(xié)議，需要設(shè)置代理，由這個代理對象去實現(xiàn)被代理執(zhí)行的工作。然而，在ios開發(fā)中，能用協(xié)議實現(xiàn)的，我們大部分都用塊直接去回調(diào)執(zhí)行，增強(qiáng)代碼的可閱讀性和緊湊性。

MVP模式的原則是，在service層提供一大堆不盡相同的業(yè)務(wù)場景之后，我們將這一系列數(shù)據(jù)全部抽象歸納，通過定制一套標(biāo)準(zhǔn)的protocol協(xié)議，讓不同業(yè)務(wù)場景的都去實現(xiàn)這一協(xié)議，最終將數(shù)據(jù)全部裝配、拼裝成一套具有相同調(diào)度規(guī)則的統(tǒng)一編制話數(shù)據(jù)Model，之后我們采用id的標(biāo)準(zhǔn)去操作數(shù)據(jù)。

MVP除了將數(shù)據(jù)邏輯完全鎮(zhèn)封的各自的Model,同時將那些Model需要繪制，哪些Model需要校驗,

哪些Model需要接受處理點擊Action這些邏輯全部由Model自己來決定，Controller只作為一個粘合性的模版，Controller只處理一批具有共性的范型類數(shù)據(jù)，至于具體的操作操作毫不關(guān)心。

MVP面相的更多的是在MVC上層與service之間追加了一層協(xié)議層，我們認(rèn)為通過協(xié)議層處理過的數(shù)據(jù)是暫時可以客戶端場景使用的數(shù)據(jù)，在數(shù)據(jù)到達(dá)MVC我們針對數(shù)據(jù)進(jìn)行再加工、再構(gòu)造處理，這一切全部在容器內(nèi)操作。這一點完全與別的設(shè)計模式相反。

MVP并不是讓用戶在Model打上網(wǎng)絡(luò)請求操作、在Model層執(zhí)行[self.navigationController pushViewController:*]等這些操作，其實相對大多人來說對于部分對象生命周期長短問題還是很在乎，所以在處理TemplateActionProtocol協(xié)議的時間，MVP只是對準(zhǔn)Action做了一層抽象封裝。通過實現(xiàn)TemplateActionProtocol的Model會產(chǎn)生一個Action對象，最終通過block的調(diào)用鏈傳回控制器中,我們在控制器中統(tǒng)一做handler處理。

MVP最初設(shè)計目的就是為了強(qiáng)調(diào)一個裝配概念，如果發(fā)生了業(yè)務(wù)場景的追加,控制器我不會改動其中的代碼，只需要將新數(shù)據(jù)追加成相同批次的ViewModel，然后配置進(jìn)容器，之后控制器不做任何修改就可以滿足需求了。通過具體的剝離、抽取我們成功了的最大限度的剝離了控制器，滿足了輕量級Controller這一概念。