可以看到，在View 与 Model 之间我们是通过 Presenter，也就是 interface 来实现view 与数据的交互的，大大降低耦合，方便进行单元测试。其实，自己在写代码的时候，心中有个概念就好了，view 就是UI，model就是数据处理，而persenter 则是他们的纽带。心中有个轮廓，写起来就不那么费劲了。

参考网站：

Android MVP开发模式 google 官方Mvp架构详解

Android MVP 详解（上）

Android MVP 详解（下）

 

为什么 MVP 是可行的？

这里有一张表格，用于展示在configuration改变、Activity 重启、Out-Of-Memory时，不同的应用部分会发生什么？

不同应用部分对不同场景的响应

情景 1: 当用户切换屏幕、更改语言设置或者链接外部的模拟器时，往往意味着设置改变。 相关更多请阅读这里。

情景 2:Activity的重启发生在当用户在开发者选项中选中了“Don’t keep activities”（“中文下为 不保留活动”）的复选框，然后另一个Activity在最顶上的时候。

情景 3: 进程的重启发生在应用运行在后台，但是这个时候内存不够的情况下。

总结

现在你可以发现，一个调用了setRetainInstance(true)的Fragment也不奏效，我们还是需要保存/恢复fragment的状态，所以为简化问题，我们暂不考虑上述情况的Fragment。

现在，看上去更舒服了，我们只需要写两段代码为了恢复应用：

· 保存/恢复 for Activity, View, Fragment, DialogFragment;

· 重启后台请求由于进程重启

第一个部分,用Android的API可以实现。第二个部分，就是Presenter的作用了。Presenter将会记住有哪些请求需要执行，当进程在执行过程中重启时，Presenter将会出现执行它们。

 

实战

 采用郭霖大神的 LitePal数据库:

http://blog.****.net/column/details/android-database-pro.html 

首先，从上面的效果图来看，我们需要 name 和 password 这两个字符串，我们需要新建一个 User 类，由于要用到 LitePal ，所以让它继承 DataSupport；如果你使用自己写的，那就不用继承啥了。

Model：

然后，我们思考一下，从View 传过来的数据name和password，我们是要保存起来的，所以，我们先在 model，编写数据保存和读取的方法：

它的具体实现方法如下:

方法很简单，就保存一下数据和读数据。什么？数据库保存这样就行了？是的，所以赶紧去学习 LitePal 吧。

View：
View这里，我们是专注于UI的显示和用户交互的，上面我们通过名字的方式从数据库中读取，然后把它显示出来。所以，我们需要添加 name 和password 的显示方法，当然还有出错的方法：

然后让mainactivity 继承这个接口重写该方法：

Presenter ：

好了，现在我们的 View 和 Model 都是单独开了的，所以，我们需要一个纽带，把view 和model 连接起来；那就是我们的 Presenter 了。

 

那么接下来，只要写onclick事件就可以了：

 

MVP模式的优缺点

我们在使用一种设计模式的时候，首先都会问，为什么要用这种模式，能给我们带来哪些方便？用了这种模式，它的缺点会不会给我的工程造成影响？ 
优点：

     (1)降低耦合度，实现了 Model 与View 的真正分离，修改 View 而不影响 Model

     (2)模块职责划分明显，层次分明，便于维护，多人开发首选。

     (3)利于测试驱动开发，模块分明，那么我们编写单元测试就变得很方便了，而不用特别是特别搭平台，人工模拟用户操作等等耗时耗力的事情。以前的Android开发是难以进行单元测试的（虽然很多Android开发者都没有写过测试用例，但是随着项目变得越来越复杂，没有测试是很难保证软件质量的；而且近几年来Android上的测试框架已经有了长足的发展——开始写测试用例吧），在使用MVP的项目中Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter应用逻辑的正确性。

     (4)代码复用，一个 Presenter可以用于多个 View，不用去改 Presenter

     (5)隐藏数据

     (6)代码灵活性

     (7)View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。

缺点： 
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。对于小工程，额外多出来的代码量，和额外的代码复杂度，毕竟那么多 interface ，但对于它的有点来说，完全可以接受。

1. Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

2. 由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。

3. 如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。

4. 额外的代码复杂度及学习成本。

小结

在MVP模式里通常包含4个要素：

(1) View :负责绘制UI元素、与用户进行交互(在Android中体现为Activity);

(2) View interface :需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试;

(3) Model :负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合);

(4) Presenter :作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。