注意：它們是軟體架構，不是設計模式
左邊mvc 右邊mvp
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如何解決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很大的不同之處。
MVP的優點
1、模型與視圖完全分離，我們可以修改視圖而不影響模型。
2、可以更高效地使用模型，因為所有的互動都發生在一個地方 —— Presenter内部。
3、我們可以将一個Presener用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁。
4、如果我們把邏輯放在Presenter中，那麼我們就可以脫離使用者接口來測試這些邏輯（單元測試）。
MVP的缺點
由于對視圖的渲染放在了Presenter中，是以視圖和Persenter的互動會過于頻繁。還有一點需要明白，如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯系過于緊密。一旦視圖需要變更，那麼Presenter也需要變更了。比如說，原本用來呈現Html的Presenter現在也需要用于呈現PDF了，那麼視圖很有可能也需要變更。