概述
MVP從MVC演變而來，通過表示器将視圖與模型巧妙地分開。在該模式中，視圖通常由表示器初始化，它呈現用戶界面（UI）并接受用戶所發出命令，但不對用戶的輸入作任何邏輯處理，而僅僅是将用戶輸入轉發給表示器。通常每一個視圖對應一個表示器，但是也可能一個擁有較複雜業務邏輯的視圖會對應多個表示器，每個表示器完成該視圖的一部分業務處理工作，降低了單個表示器的複雜程度，一個表示器也能被多個有着相同業務需求的視圖複用，增加單個表示器的複用度。表示器包含大多數表示邏輯，用以處理視圖，與模型交互以獲取或更新數據等。模型描述了系統的處理邏輯，模型對于表示器和視圖一無所知。
模型-視圖-控制器(MVC)模式是一個框架級的設計模式，該模式将軟件設計中的關注點分離開來，從而使程序更有彈性。随着軟硬件的發展，基于MVC模式演化出了一些相關模式。模型-視圖-表示器(MVP)模式就是由MVC演變而來。
MVP的全稱為Model-View-Presenter，Model提供數據，View負責顯示，Controller/Presenter負責邏輯的處理。MVP與MVC有着一個重大的區别：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter(MVC中的Controller)來進行的，所有的交互都發生在Presenter内部，而在MVC中View會直接從Model中讀取數據而不是通過Controller。
MVP模式(Model-View-Presenter)可以說是MVC模式(Model-View-Controller)在Android開發上的一種變種、進化模式。
優勢
MVP模式下表示層的優勢體現在下面三個方面：
1、View與Model完全隔離。
得益于此，Model和View之間具有良好的松耦合設計，這意味着，如果Model或View中的一方發生變化，隻要交互接口不變，另一方就沒必要對上述變化做出改變。這使得Model層的業務邏輯具有很好的靈活性和可重用性。
2、Presenter與View的具體實現技術無關。
也就是說，采用諸如Windows表單，WPF，Web表單等用戶界面構建技術中的任意一種來實現View層，都無需改變系統的其他部分。甚至為了使B/S，C/S部署架構能夠被同時支持，應用程序可以用同一個Model層适配多種技術構建的View層。
3、可以進行View的模拟測試。
過去，由于View和Model之間的緊耦合，在Model和View同時開發完成之前對其中一方進行測試是不可能的。出于同樣的原因，對View或Model進行單元測試很困難。現在，MVP模式解決了所有的問題。在MVP模式中，View和Model之間沒有直接依賴，開發者能夠借助模拟對象注入測試兩者中的任一方。
MVC&MVP
MVP是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。作為一種新的模式，MVP與MVC有着一個重大的區别：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter(MVC中的Controller)來進行的，所有的交互都發生在Presenter内部，而在MVC中View會從直接Model中讀取數據而不是通過Controller。
在MVC裡，View是可以直接訪問Model的。從而，View裡會包含Model信息，不可避免的還要包括一些業務邏輯。在MVC模型裡，更關注的Model的不變，而同時有多個對Model的不同顯示及View。所以，在MVC模型裡，Model不依賴于View，但是View是依賴于Model的。不僅如此，因為有一些業務邏輯在View裡實現了，導緻要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
問題改進方式
在MVP裡，Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter裡實現。而且，Presenter與具體的View是沒有直接關聯的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，即重用。不僅如此，我們還可以編寫測試用的View，模拟用戶的各種操作，從而實現對Presenter的測試--而不需要使用自動化的測試工具。我們甚至可以在Model和View都沒有完成時候，就可以通過編寫MockObject（即實現了Model和View的接口，但沒有具體的内容的）來測試Presenter的邏輯。在MVP裡，應用程序的邏輯主要在Presenter裡實現，其中的View是很薄的一層。因此就有人提出了PresenterFirst的設計模式，就是根據UserStory來首先設計和開發Presenter。在這個過程中，View是很簡單的，能夠把信息顯示清楚就可以了。在後面，根據需要再随便更改View，而對Presenter沒有任何的影響了。如果要實現的UI比較複雜，而且相關的顯示邏輯還跟Model有關系，就可以在View和Presenter之間放置一個Adapter。由這個Adapter來訪問Model和View，避免兩者之間的關聯。而同時，因為Adapter實現了View的接口，從而可以保證與Presenter之間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。在MVP模式裡，View隻應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的内容，除此就不應該有更多的内容，絕不容許直接訪問Model--這就是與MVC很大的不同之處。
優點
MVP與MVC的主要區别是View與Model不直接交互，而是通過與Presenter來完成交互，這樣可以修改視圖而不影響模型，達到解耦的目的，實現了Model和View真正的完全分離。視圖的變化總是比較頻繁，将業務邏輯抽取出來，放在表示器中實現，使模塊職責劃分明顯，層次清晰，一個表示器能複用于多個視圖，而不需要更改表示器的邏輯（當然是在該視圖的改動不影響業務邏輯的前提下），這增加了程序的複用性。數據的處理由模型層完成，隐藏了數據，在數據顯示時，表示器可以對數據進行訪問控制，提高數據的安全性。以前的Android開發是難以進行單元測試的，但是随着項目變得複雜，測試時保證應用質量的關鍵，MVP模式中，表示器對視圖是通過接口進行的，可以利用測試驅動，模拟出視圖對象，實現視圖相對于表示器的接口，就可以對表示層進行不依賴于UI環境的單元測試了，這大大降低了Android應用開發中的業務邏輯測試難度和複雜度。MVP模式的引入，視圖層完全不依賴與模型層，相當于将視圖從特定的業務場景中脫離出來，做到了對業務完全不可知的狀态，因此可以将視圖層組件化，提供一系列接口供表示層操作，這樣就可以做出高度可複用的視圖組件了。
缺點
MVP的明顯缺點是增加了代碼的複雜度，特别是針對小型Android應用的開發，會使程序冗餘。Presenter中除了應用邏輯以外，還有大量的View->Model，Model->View的手動同步邏輯，會導緻Presenter臃腫，維護困難。視圖的渲染過程也會放在Presenter中，造成視圖與Presenter交互過于頻繁，如果某特定視圖的渲染很多，就會造成Presenter與該視圖聯系過于緊密，一旦該視圖需要變更，那麼Presenter也需要變更了，不能如預期的那樣降低耦合度和增加複用性。
