MVP的初步認識

為何MVP模式能在Android開發中大放異彩，我覺得很大一部分原因來源與傳統的model-view的開發模式使得everything is connected with Activity。MVP開發模式使一部分的業務邏輯從Activity中抽取出來。

那MVP是怎樣的呢？

我們先理清M(model)V(view)P(presenter)他們各自的職責

V(view)界面層：負責與用戶交互展示數據與刷新界面

P(presenter)業務邏輯層：主要負責處理業務邏輯

M(model)數據訪問層：負責數據載入

用一張圖一句話大概的概括下他們之間的流程：

View層在交互需要數據時通知Presenter層，讓Presenter去向Model層要數據，當model層載入好數據後通過回調傳給Presenter層，Presenter在拿到數據後對數據進行業務邏輯處理，在處理完成後發送給View進行更新界面。

通過一個Demo來貫通下流程:Github地址先看下項目整體結構：

View層

在我看來View層的理想狀態應該是只有三類方法，分別是

initView();//初始化控制項 loadData();//向Presenter請求數據 setView(Data data);//將Presenter處理完的數據傳遞給View顯示

View在項目中可以是多個，根據實際項目情況可以將某一頁面或則某一部分控制項劃分在一個View下，通常Activity和Fragment也劃分在View層，我們來看下項目中MainActivity.java的代碼:

/** * 初始化視圖 */ @Override public void initView() { setContentView(R.layout.activity_main); jokelistview = (ListView) this.findViewById(R.id.lv_joke); tv_toast = (TextView) this.findViewById(R.id.tv_toast); } @Override public void loadData() { jokeAdapter = new JokeListViewAdapter(this,resultBeanList); jokelistview.setAdapter(jokeAdapter); //通知presenter載入數據 jokePresenterimpl.getJoke(PAGER_NUM,PAGER_SIZE); } /** * 將presenter處理完成的數據傳給View * @param jokeResult */ @Override public void setJoke(JokeResult jokeResult) { if(jokeResult!=null){ resultBeanList = jokeResult.getResult(); if(resultBeanList!=null){ jokeAdapter.addAll(resultBeanList); } } }Presenter層

當View層在loadData()中通過調用presenter的getJoke()來載入數據時，通知model的載入數據的方法來載入數據，如項目中JokePresenterimpl.java的getJoke()方法：

@Override public void getJoke(int pagerNum, int size) { jokeView.showloading(); //通知model層來載入數據 jokeModel.getJoke(pagerNum, size, new JokeModel.JokeLoadListener() { //在onSucess（）和onError（）方法中做業務邏輯處理（這裡沒啥可處理的），處理完成通知View更新界面 @Override public void onSucess(JokeResult response) { //通知View層更新界面 jokeView.setJoke(response); jokeView.hideloading(); } @Override public void onError() { //通知View層更新界面 jokeView.loadErr(); } }); }Model層

model層就比較簡單了，只是簡單的做數據的載入操作，在載入數據完成時，通過介面回調給presenter層做數據業務邏輯處理：

/** * 載入數據 */ @Override public void getJoke(int page, int size,JokeLoadListener jokeListener) { this.jokeLoadListener=jokeListener; VolleyRequest.newInstance().newGsonRequest(joke_url + "key=" + app_key + "&page=" + page + "&rows" + size, JokeResult.class , new Response.Listener() { @Override public void onResponse(JokeResult response) { //將載入結果回調給presenter層 if(response==null){ jokeLoadListener.onError(); }else{ jokeLoadListener.onSucess(response); } } }, new Response.ErrorListener() { @Override public void onErrorResponse(VolleyError error) { //將載入結果回調給presenter層 jokeLoadListener.onError(); } }); }小結

MVP模式相對於傳統的Model-View模式一定程度上的使得業務邏輯處理與View層分離，相對於MVC模式降低了代碼的耦合，但是在我看來MVP模式在Android開發中使用還是有一定的不足

代碼量增

Activity的界線劃分不明確，放在View層的話Intent的傳遞，FragmentTransaction等操作出現位置不對，使得View層不能與業務邏輯層撇清

View層與Presenter層關係過於緊密，不利於後期維護

其中將Activity與Fragment放置在Presenter層有一個有趣的例子可以一看（一種在android中實現MVP模式的新思路），但是在項目中不能為了模式而模式，否則後期擴展會讓人崩潰。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！