![MVP[MVP模式]](/img/8/c7b/n5GcuM3X2YTM0IDO2gDN1ADM4QTMxUTMyUDM0QTNwAzMwIzL4QzL3AzLt92YucmbvRWdo5Cd0FmLyE2LvoDc0RHa.jpg "MVP[MVP模式]")
簡介
MVPMVP與MVC有著一個重大的區別：在MVP中View並不直接使用Model，它們之間的通信是通過Presenter(MVC中的Controller)來進行的，所有的互動都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是通過Controller。
和MVC的區別
MVP模式作為一種新的模式，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也是比較困難的，至少那些業務邏輯是無法重用的。
雖然MVC中的View的確“可以”訪問Model，但是我們不建議在View中依賴Model，而是要求儘可能把所有業務邏輯都放在Controller中處理，而View只和Controller互動。上面的這段文字不知是什麼水平的開發者編輯的，基本邏輯都不清楚。
解決問題方式
在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很大的不同之處。
優缺點
優點
1、模型與視圖完全分離，可以修改視圖而不影響模型。
2、可以更高效地使用模型，因為所有的互動都發生在一個地方——Presenter內部。
3、可以將一個Presenter用於多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁。
4、如果把邏輯放在Presenter中，那么就可以脫離用戶接口來測試這些邏輯（單元測試）。
缺點
由於對視圖的渲染放在了Presenter中，所以視圖和Presenter的互動會過於頻繁。還有一點需要明白，如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯繫過於緊密。一旦視圖需要變更，那么Presenter也需要變更了。比如說，原本用來呈現Html的Presenter現在也需要用於呈現Pdf了，那么視圖很有可能也需要變更。
