MVC和MVP在App中的對比分析以及實際應用

在開發Android應用時，相信不少同窗遇到和我同樣的狀況，雖然項目剛開始構架時自認爲MVC層級分的特別明確，但最終每每是一個Activity有上千行代碼，並且業務邏輯和UI的顯示混雜在一塊兒，致使後續項目的維護成本巨大。

一個偶然的機會看到有種MVP模式（Mode-View-Presenter）能夠比MVC更好地解耦和，而後好奇地研究了下這個模式並嘗試在如今項目中進行推廣。下面我將本身目前學習到的知識進行一個總結。

1.對比MVC與MVP

我理解的MVP是由MVC優化衍生出來的一種模式，MVP將MVC中的Controller層進行了優化而生成了Presenter。Presenter單詞翻譯爲「提出者/任命者/主持人」，Presenter層和MVC的Controller同樣，負責核心邏輯，但不同的是Presenter經過接口協議進行數據傳遞，並阻斷了View和Model的直接聯繫，從而使View和Model更加專一於自身業務邏輯。

● View

View一般來講就是由Activity、Fragment實現的，View會包含一個或多個Presenter的引用來知足視圖的業務邏輯。View和Presenter的交互是雙向的，即View層能夠調用Presenter的邏輯方法，Presenter也能夠控制View的顯示。

● Presenter

Presenter做爲Model和View的橋樑，負責從Model拿到數據進行處理並返回給View。但Presenter和其餘兩層的溝通是經過接口協議進行的，因此每一個Presenter中一般會包涵一個或多個接口協議。

● Model

和MVC同樣，做爲數據倉庫只負責對App數據進行處理。

在MVC裏，View是能夠直接訪問Model的！從而，View裏會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型裏，更關注Model的不變，而同時有多個對Model的不一樣顯示，及View。

因此，在MVC模型裏，Model不依賴於View，可是 View是依賴於Model的。不只如此，由於有一些業務邏輯在View裏實現了，致使要更改View也是比較困難的，至少那些業務邏輯是沒法重用的。

2.MVP如何解決MVC的問題

在MVP裏，Presenter徹底把Model和View進行了分離，主要的程序邏輯在Presenter裏實現。並且，Presenter與具體的View是沒有直接關聯的，而是經過定義好的接口進行交互，從而使得在變動View時候能夠保持Presenter的不變，即重用！

不只如此，咱們還能夠編寫測試用的View，模擬用戶的各類操做，從而實現對Presenter的測試，而不須要使用自動化的測試工具。咱們甚至能夠在Model和View都沒有完成的時候，就能夠經過編寫Mock Object（即實現了Model和View的接口，但沒有具體的內容的）來測試Presenter的邏輯。

在MVP裏，應用程序的邏輯主要在Presenter來實現，其中的View是很薄的一層。所以就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發Presenter。在這個過程當中，View是很簡單的，可以把信息顯示清楚就能夠了。在後面，根據須要再隨便更改View，而對Presenter沒有任何的影響了。

若是要實現的UI比較複雜，並且相關的顯示邏輯還跟Model有關係，就能夠在View和Presenter之間放置一個Adapter。由這個Adapter來訪問Model和View，避免二者之間的關聯。而同時，由於Adapter實現了View的接口，從而能夠保證與Presenter之間接口的不變。這樣就能夠保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。

在MVP模式裏，View只應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的內容，除此就不該該有更多的內容，毫不允許直接訪問Model—— 這就是與MVC很大的不一樣之處。

3.MVP的優勢

◆ 模型與視圖徹底分離，咱們能夠修改視圖而不影響模型；

◆ 能夠更高效地使用模型，由於全部的交互都發生在一個地方——Presenter內部；

◆ 咱們能夠將一個Presenter用於多個視圖，而不須要改變Presenter的邏輯。這個特性很是的有用，由於視圖的變化老是比模型的變化頻繁；

◆ 若是咱們把邏輯放在Presenter中，那麼咱們就能夠脫離用戶接口來測試這些邏輯（單元測試）。

MVP主要解決的就是把邏輯層抽出來成P層。若是遇到需求業務邏輯上的更改，能夠只修改P層，或者遇到邏輯上的大改，也能夠直接重寫一個P層。不少開發人員把全部的東西都寫在了Activity/Fragment裏面，這樣一來，遇到頻繁的需求變動和愈來愈複雜的邏輯時，Activity /Fragment裏面就會出現過多的耦合邏輯致使出錯。

因此，從控制邏輯和UI的解耦的角度來看，MVP模式是一個不錯的選擇！