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 这个流行的依赖注入框架。