一、概述
MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數(shù)據(jù)，View負責顯示。
二、MVC和MVP的區(qū)別
作為一種新的模式，MVP與MVC有著一個重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進行的，所有的交互都發(fā)生在Presenter內部，而在MVC中View會直接從Model中讀取數(shù)據(jù)而不是通過 Controller。在MVC里，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的還要包括一些業(yè)務邏輯。?
在MVC模型里，更關注的Model的不變，而同時有多個對Model的不同顯示，即View。所以，在MVC模型里，Model不依賴于View，但是View是依賴于Model的。不僅如此，因為有一些業(yè)務邏輯在View里實現(xiàn)了，導致要更改View也是比較困難的，至少那些業(yè)務邏輯是無法重用的。

? ? ? ?MVP模式實現(xiàn)了蘋果提倡的MVC模式，將Model和View完全隔離。
三、MVP如何解決MVC的問題
在MVP里，Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現(xiàn)。而且，Presenter與具體的View是沒有直接關聯(lián)的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，即重用！ 不僅如此，我們還可以編寫測試用的View，模擬用戶的各種操作，從而實現(xiàn)對Presenter的測試--而不需要使用自動化的測試工具。 我們甚至可以在Model和View都沒有完成時候，就可以通過編寫Mock Object（即實現(xiàn)了Model和View的接口，但沒有具體的內容的）來測試Presenter的邏輯。
在MVP里，應用程序的邏輯主要在Presenter來實現(xiàn)，其中的View是很薄的一層。因此就有人提出了Presenter First的設計模式，就是根據(jù)User Story來首先設計和開發(fā)Presenter。在這個過程中，View是很簡單的，能夠把信息顯示清楚就可以了。在后面，根據(jù)需要再隨便更改View，而對Presenter沒有任何的影響了。? 如果要實現(xiàn)的UI比較復雜，而且相關的顯示邏輯還跟Model有關系，就可以在View和Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關聯(lián)。而同時，因為Adapter實現(xiàn)了View的接口，從而可以保證與Presenter之間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。? 在MVP模式里，View只應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的內容，除此就不應該有更多的內容，絕不容許直接訪問Model。
? ? ? ? 實現(xiàn)MVP時，應該由UIViewController來充當Presenter的角色，然后把UIViewController的View子類化，將View邏輯單獨抽離出來管理。 四、MVP的優(yōu)點
1、模型與視圖完全分離，我們可以修改視圖而不影響模型 2、可以更高效地使用模型，因為所有的交互都發(fā)生在一個地方——Presenter內部 3、我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁。 4、如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）
五、MVP的缺點
由于對視圖的渲染放在了Presenter中，所以視圖和Presenter的交互會過于頻繁。還有一點需要明白，如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯(lián)系過于緊密。一旦視圖需要變更，那么Presenter也需要變更了。比如說，原本用來呈現(xiàn)Html的Presenter現(xiàn)在也需要用于呈現(xiàn)Pdf了，那么視圖很有可能也需要變更。
轉自：http://baike.baidu.com/subview/7294/10754970.htm#viewPageContent

總結

以上是生活随笔為你收集整理的MVP模式介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。