为何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<JokeResult>() {
@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模式的新思路),但是在项目中不能为了模式而模式,否则后期扩展会让人崩溃。
参考博文:
Android架构设计—MVP模式第(一)篇之基本认实
浅谈 MVP in Android
Android MVP 详解(上)