MVP 模式之初识 MVP(1)

其实感觉应该叫做 MVP 模式之我见~,作为一个菜鸟其实我对 MVP 模式还不是特别理解,所以文中必然会有这样那样的错误的存在,希望各位大佬不吝赐教!

为什么要有 MVP

相信大家要是看过别的文章的话肯定很理解这一点,那就是我们的 Activity 太“重”了,这里的重不仅仅是指代码量大,更多的是指他承载的任务种类太多了。既要渲染页面、网络加载处理、数据库读写等等,我们把一个页面中的所有任务几乎都放到了 Activity 中来处理。对于一个小项目可能这还没什么问题,可如果是一个大项目,那么对日后的维护而言简直就是噩梦。

软件开发的一个主旨就是“高内聚、低耦合”,而在这种所有代码都放到 Activity 中的做法,显然是背离这个主旨的。而且这个写法对于测试而言也是困难重重,因为所有的代码都“耦合”在这一个 Activity 文件中。

MVP 模式的设计理念其实就是将原来的 Activity 进行分层,使其职责单一,只负责对 View 的渲染与处理。将获取数据的操作(获取网络数据、获取本地数据库数据)放到M层(Model),至于其他的操作处理全部都放到P层(Presenter)中。将V层与M层彻底解耦, Activity 不再关心数据如何获取,只关注将获取的数据渲染到视图上即可。这样做的好处是:各层之间耦合减少,便于单元测试!

当我们所有操作都写在 Activity 中时,如果要进行测试只有将代码编译打包到手机或者模拟器上运行。如果只是一些小小的改动,功能并不涉及到 Android 环境,这样做的代价显然是太大了。当V层与M层彻底解耦后就不一样了,因为V层并不知道M层的存在,我们可以直接对M层进行单元测试,无需依赖 Android 的环境。同理当我们进行 UI 测试时,可以通过 Mock 测试用数据来检查V层是否可以正常显示,而无需依赖后台

V层与P层互相持有彼此对象,通过接口进行通信

如何实现MVP

上面的图示总我写到“V层与P层互相持有彼此对象,通过接口进行通信”,这句话就是实现MVP模式的重点,我们将原本都放置在Activity中的操作,抽象形成接口。

我们将视图层的操作抽象成 View 接口,然后在 Activity 中,我们实现这些方法。比如一个加载列表的页面抽象接口如下所示:

1
2
3
4
5
6
public interface View{
void showLoading(); //显示加载中
void hideLoading(); //加载成功隐藏
void showError(); //加载失败显示错误
void showList(List<String> data); //加载数据
}

我们将数据获取之类的操作抽象成 Presenter 接口,在 Presenter 实现类中实现。如下所示:

1
2
3
public interface Presenter{
void getData();
}

这种写法会导致我们要创建大量的接口文件,Google 推荐我们的做法是使用 Contract 类来管理接口,如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
public interface Contract {

interface View {
void showLoading(); //显示加载中
void hideLoading(); //加载成功隐藏
void showError(); //加载失败显示错误
void showList(List<String> data); //加载数据
}

interface Presenter extends BasePresenter {
void getData();
}
}

可以看到我们的P层接口中只写了一个方法就是获取数据,那么你可能要问了,这两者之间如何建立联系,P层获取到数据后怎么才能显示到 Activity 中的 ListView中呢?

这就要提到我在上面提到的那句话了,“V层与P层互相持有彼此对象,通过接口进行通信”。实现方式如下所示:

在V层中实例化 Presenter 实现类对象, Presenter 实现类的构造方法中有一个V层参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class PresenterImpl implements Contract.Presenter{

Contract.View mView;

public PresenterImpl(Contract.View view) {
mView = view;
}

@Override
public void getData(){
List<String> data = Arrays.asList("1","2","3","4","5","6");
mView.showList(data); //调用V层的显示方法,将数据传递至V层
}
}

Activity 实现 View 接口,实例化Presenter 实现类时,传入 this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class MainActivity extends AppCompatActivity implements Contract.View {

private Contract.Presenter mPresenter;
...
...

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mPresenter = new PresenterImpl(this);
}
...
...

@Override
public void showList(List<String> data) {
mAdapter.addAll(data);
mAdapter.notifyDataSetChanged();
}
}

其他方式: 还可以使用 Dagger 依赖注入的方式来完成,可以参考谷歌的示例 MVP-Dagger,其实核心思想都是“V层与P层互相持有彼此对象”

本次文章就写到这里啦,参考本文可以搭出一个简单的 MVP 模式的架子,在行文途中感到自己对 MVP 模式的了解还只是一知半解,但却也着实体会到了其必要性,下一篇文章将带来 MVP + Dagger2 。参考谷歌的示例项目,进一步理解 MVP 模式,以及 Dagger 这个流行的依赖注入框架。