之前一直用的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代码。
