在開發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里，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模式是一個不錯的選擇！