轉載地址：http://frodoking.github.io/2015/02/01/android-mvc-mvp-analysis/

為了解決邏輯處理和UI視圖的松散耦合，MVC和MVP的架構模式在很多App中使用比較廣泛。

那什么是MVP呢？它又和我們常常聽到的MVC有什么關系了以及區別呢？

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、我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁；
4、如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）。

使用方法

1、建立bean

public class UserBean {private String mFirstName;private String mLastName;public UserBean(String firstName, String lastName) {this. mFirstName = firstName;this. mLastName = lastName;}public String getFirstName() {return mFirstName;}public String getLastName() {return mLastName;} }

2、建立model接口（處理業務邏輯，這里指數據讀寫）

public interface IUserModel {void setID(int id);void setFirstName(String firstName);void setLastName(String lastName);int getID();UserBean load(int id);// 通過id讀取user信息,返回一個UserBean }

3、建立view接口（更新ui中的view狀態），這里列出需要操作當前view的方法

public interface IUserView {int getID();String getFristName();String getLastName();void setFirstName(String firstName);void setLastName(String lastName); }

4、建立presenter（主導器，通過iView和iModel接口操作model和view），activity可以把所有邏輯給presenter處理，這樣java邏輯就從手機的activity中分離出來

public class UserPresenter {private IUserView mUserView;private IUserModel mUserModel;public UserPresenter(IUserView view) {mUserView = view;mUserModel = new UserModel();}public void saveUser( int id, String firstName, String lastName) {mUserModel.setID(id);mUserModel.setFirstName(firstName);mUserModel.setLastName(lastName);}public void loadUser( int id) {UserBean user = mUserModel.load(id);mUserView.setFirstName(user.getFirstName()); // 通過調用IUserView的方法來更新顯示mUserView.setLastName(user.getLastName());} }

結束語

MVP主要解決就是把邏輯層抽出來成P層，要是遇到需求邏輯上的更改就可以只需要修改P層了或者遇到邏輯上的大概我們可以直接從寫一個P也可以，很多開發人員把所有的東西都寫在了Activity/Fragment里面這樣一來遇到頻繁改需求或者邏輯越來越復雜的時候，Activity/Fragment里面就會出現過多的混雜邏輯導致出錯，所以MVP模式對于APP來對控制邏輯和UI的解耦來說是一個不錯的選擇！

在這里多說一下，其實MVP只是一個總體的解決方案。在V和P之間其實我們還可以采用事件總線的方案來解決這種高耦合的情況。本人在另外一篇文章中將會講到

事件總線（otto的bus和eventbus的一個對比分析） http://frodoking.github.io/2015/03/30/android-eventbus-otto-analysis/

總結

以上是生活随笔為你收集整理的Android之mvp和mvc对比分析以及实际应用的全部內容，希望文章能夠幫你解決所遇到的問題。

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