目前关于mvp架构实现的例子相当之多，这里总结了一下社区对于mvp架构实现的几点忠告。
假如你打算将MVP模式引入到你的项目中，那么你将不得不去面对android开发中常见的一些问题，如Activity的生命周期及以下：
- 是否该保存presenter的状态
- 是否该持久化presenter
- 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<Repository> 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<View> {
void load();
void loadMore();
void queryChanged(String query);
void repositoryClick(Repository repo);
}
}
如果将View和presenter分开到单独的文件中，那么将会出现
public interface SearchView{
void addResults(List<Repository> 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<View> {
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<V> {
void attach(V view);
void detach();
}
这种方式不是更加直接吗？在view需要用到presenter时attached，在view不可用时detach，我没有想出这哪里不够用的了。
5. view的状态应该有model来持久化，并非是presenter
repository.get(params)这样的一个操作封装在model层即可，如果view数据已经缓存，直接读取即可，如果没有，在从api拉取，presenter真心不应该去做页面状态恢复的工作。
