之前一直用的MVC模式,但是业务逻辑稍微复杂,MVC的缺点就暴露了:View和modle杂糅在一起,有时候为了代码书写方便,把所有逻辑都写在Activity里面,经常导致Activity代码超过1000行,虽然多少行代码并没有什么实际意义,但耦合度高总不是我们想要的,于是就想尝试一下MVP模式(虽然大部分人都已经用上了),之前的想法是先把一个最复杂的模块替换为MVP模式试用一段时间,于是花了3天时间把这个模块从MVC替换为MVP,自己去查MVP资料总感觉不够理解,真正动手做了一遍发现理解难度大大降低,并且尝试到了MVP的甜头,最后产品经理更改登陆模块需求的时候果断把登陆模块也替换为MVP模式(一发不可收拾),下面记录下我对MVP模式的理解。
MVP的思想是一样的,但是写法每个人都不一样,我参考的例子是: https://github.com/antoniolg/androidmvp
MVP的优势:UI、逻辑分离(类似于前端的前后端分离),逻辑非常清晰
MVP的劣势:上手有难度,代码量比较大
对于一个想长期维护的项目来说,优势的影响远远大于劣势的影响,所以果断上手吧。
本博客记录的MVP模式的结构如下图:
这里写图片描述
从结构图可以看到,与Activity交互的只有View和Presenter,所有逻辑交互都放在presenter里面处理。
举个例子:有个显示列表的界面,可以通过下拉刷新请求数据并刷新view。
1、定义Listener : GetDataListener
public interface GetDataListener{
void onGetDataSuccess(List<Data> data);
void onGetDataFail();
}
2、定义Interactor:GetDataInteractor
public interface GetDataInteractor{
void getData();
}
3、实现Interactor:GetDataInteractorImpl
public interface GetDataInteractorImpl implements GetDataInteractor{
@Override
public void getData(Params params, GetDataListener listener){
request(Params params){
@Override
public void onRequestSuccess(List<Data> data){
listener.onGetDataSuccess(data);
}
@Override
public void onRequestFail(){
listener.onGetDataFail();
}
}
});
}
4、定义View
public interface TestView{
void refreshData(List<Data> dataList);
}
5、定义Presenter
public interface Presenter{
void requestData();
}
6、实现Presenter:PresenterImpl
public class PresenterImpl implements Presenter,GetDataListener{
TestView mView;
GetDataInteractor mInteractor;
List<Data> mDataList;
public PresenterImpl(TestView view){
this.mView = view;
mInteractor = new GetDataInteractorImpl();
}
@Override
public void requestData(){
mInteractor.getData(params, this);
}
@Override
public void onGetDataSuccess(List<Data> dataList){
mDataList = dataList;//mDataList.addAll(dataList);
mView.refreshData(mDataList);
}
@Override
public void onGetDataFail(){
//do something....
}
}
7、定义Activity
public class TestActivity extends Activity implements TestView{
ListView mListView;
Presenter mPresenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_register);
init();
}
private void init(){
mListView = (ListView)findViewById(R.id.listview);
mPresenter = new PresenterImpl(this);
mListView.setOnItemClickListener(new OnItemClickListener() {
//假如点击一次就刷新
mPresenter.requestData();
});
}
public void refreshData(List<Data> dataList){
mListView.otifyDataSetChange();
}
}
如此7步,一个简单的mvp模式的例子就完成了,可以看到,数据List<Data>保存在PresenterImpl里面,Activity只负责显示,Activity不负责任何逻辑(非常简单的逻辑可以写在Activity里面)。
如果后台想改接口,换成另一个接口来请求数据,非常简单,在Interactor里面改就行了,如果基本数据不变,照常返回的数据还是Data,则其他地方根本不用动,如果Data结构变化,只需要改Interactor和Presenter就行了,Activity和View不用动。
如果产品经理改需求,需要在请求的时候加上Loading效果,同样非常简单,在View增加一个showLoading和hideLoading接口,然后在Activity实现,这样在Presenter里面任何时候想调用就可以随时mView.showLoading,完全不用管showLoading具体怎么实现。
从以上例子可知,UI和逻辑的分离带给我们的好处有多大,整个模块逻辑非常清晰,更改需求也非常简单,赶快上手吧。
代码量确实有比较大的增加,可以考虑开发一个android studio插件自动生成presenter、interactor、Listener代码。
网友评论