mvp设计指南

目前关于mvp架构实现的例子相当之多，这里总结了一下社区对于mvp架构实现的几点忠告。

假如你打算将MVP模式引入到你的项目中，那么你将不得不去面对android开发中常见的一些问题，如Activity的生命周期及以下：

1. 是否该保存presenter的状态
2. 是否该持久化presenter
3. presenter是否应该有生命周期

3个问题，本文将围绕这些常见的问题展开讨论，顺便给出一些best practice 和 guidelines。

首先来看一下，MVP三个角色之前的关系图吧。

MVP设计模式

• Model：负责管理数据的。从细的方面说，使用RESTFUL API,缓存数据，操作数据库，读写pref等等，都应该是Model的职责范围。业界对于Model的实现，有两种方式，个人觉得都是合理的。对于Repository pattern 党，model可能是Repository，而对于Clean architecture 党 model可能是Interactor，然而，这都没有什么问题。
• Presenter：负责给Model和View牵线搭桥的，可以理解为中间人，他阻断了Model和View直接沟通。从细的方面讲，所有的业务逻辑都应该放在这里。用户对于view的任何操作的内部表现为presenter去请求相关model作出处理，然后使用model处理后的结果来反过来在更新View。
• View：仅仅负责展现数据，View不仅仅局限于Activity，Fragment，事实上所有用户可见或可以交互的都能称得上是View这层的范畴。

接下来讲的几点是关于MVP设计原则的

1. 彻底让View变成一个任人摆布的傀儡吧！

试着想一想，View没有了任何的业务逻辑，全部都抽到presenter中之后，View剩下的工作实际上只是展示数据而已，列表也好，详情也罢，空页面也是如此。而presenter中全部都是与View无关的一些复杂的数据处理逻辑，测试将不会依赖android ui framework，可测试性将大大提高，不是吗？

2. presenter彻底与UI脱离！

presenter并没有必要知道android ui的存在，他只是负责数据处理逻辑而已，数据，本身应该不依赖于UI而存在，因此，当你的presenter中存在activity，textview等这些鬼时，那么你是时候考虑，是否真的需要这些ui层面上的东西了。有人可能会问了，那假如需要context获取pref呢？这个问题也的确很棘手，事实上也是有办法规避的，比如，拿pref的工作交给View去做吧。这里pref尽可能的封装好，避免view中去写逻辑操作pref。

3. 将View和presenter定义在一个contract中！

实际上你也可以不必这么做，但是为什么这里要拿出来说，实际上也是因为遇到过问题的

public interface SearchRepositoriesContract {
  interface View {
    void addResults(List repos);
    void clearResults();
    void showContentLoading();
    void hideContentLoading();
    void showListLoading();
    void hideListLoading();
    void showContentError();
    void hideContentError();
    void showListError();
    void showEmptyResultsView();
    void hideEmptyResultsView();
  }
  interface Presenter extends BasePresenter {
    void load();
    void loadMore();
    void queryChanged(String query);
    void repositoryClick(Repository repo);
  }
}

如果将View和presenter分开到单独的文件中，那么将会出现

public interface SearchView{
    void addResults(List repos);
    void clearResults();
    void showContentLoading();
    void hideContentLoading();
    void showListLoading();
    void hideListLoading();
    void showContentError();
    void hideContentError();
    void showListError();
    void showEmptyResultsView();
    void hideEmptyResultsView();
  }

public interface SearchPresenter extends BasePresenter {
    void load();
    void loadMore();
    void queryChanged(String query);
    void repositoryClick(Repository repo);
  }

那么，假如项目业务繁多，20个，30个..100个呢？文件数也就随之比写到一个contract中多了不少。而且还有一个好处，一眼便知presenter有哪些逻辑，view有哪些呈现样式。

4. 不要在presenter中去写Activity方式的生命周期回调。

`onCreate(...), onStart(), onResume() ...`，我一直认为这些并没有什么鸟用，假如你实现的View不是一个Activity，二十一个ViewGoup呢，是不是还会出现一些ViewAttatch之类的诡异接口来，而且

public interface BasePresenter {
  void attach(V view);
  void detach();
}

这种方式不是更加直接吗？在view需要用到presenter时attached，在view不可用时detach，我没有想出这哪里不够用的了。

5. view的状态应该有model来持久化，并非是presenter

repository.get(params)这样的一个操作封装在model层即可，如果view数据已经缓存，直接读取即可，如果没有，在从api拉取，presenter真心不应该去做页面状态恢复的工作。