http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0227/2503.html
MVP作为一种MVC的演化版本在Android开发中受到了越来越多的关注，但在项目开发中选择一种这样的软件设计模式需保持慎重心态，一旦确定 使用MVP作为你App的开发模式那么你就最好坚持做下去，如果在使用MVP模式开发过程中发现问题而且坑越来越大，这时你想用MVC等来重新设计的话基 本上就等于推倒重来了。要知道在Android上MVP在现在为止并没有统一的标准或者框架，不像SSH这三个成熟稳重强而有力的三剑客支持推动着 Java EE的开发，所以在运用MVP时一定要做好自己的理解，并且尽量预知自己App各模块的需求（客户说改改改，我们就改改改 :-( ）以便提前做好充分的设计工作。当然MVP既然能出现那么必然有它的优点的，不然谁会理会这个冒出来的东西，下面就对Android中MVP做一些阐述。
MVP简介
相信大家对MVC都是比较熟悉了：M-Model-模型、V-View-视图、C-Controller-控制器，MVP作为MVC的演化版本，那么类似的MVP所对应的意义：M-Model-模型、V-View-视图、P-Presenter-表示器。 从MVC和MVP两者结合来看，Controlller/Presenter在MVC/MVP中都起着逻辑控制处理的角色，起着控制各业务流程的作用。而 MVP与MVC最不同的一点是M与V是不直接关联的也是就Model与View不存在直接关系，这两者之间间隔着的是Presenter层，其负责调控 View与Model之间的间接交互，MVP的结构图如下所示，对于这个图理解即可而不必限于其中的条条框框，毕竟在不同的场景下多少会有些出入的。在 Android中很重要的一点就是对UI的操作基本上需要异步进行也就是在MainThread中才能操作UI，所以对View与Model的切断分离是 合理的。此外Presenter与View、Model的交互使用接口定义交互操作可以进一步达到松耦合也可以通过接口更加方便地进行单元测试。
MVP结构图
MVP之Model
模型这一层之中做的工作是具体业务逻辑处理的实现，都伴随着程序中各种数据的处理，复杂一些的就明显需要实现一个Interface来松耦合了。
MVP之View
视图这一层体现的很轻薄，负责显示数据、提供友好界面跟用户交互就行。MVP下Activity和Fragment体现在了这一 层，Activity一般也就做加载UI视图、设置监听再交由Presenter处理的一些工作，所以也就需要持有相应Presenter的引用。例 如，Activity上滚动列表时隐藏或者显示Acionbar（Toolbar），这样的UI逻辑时也应该在这一层。另外在View上输入的数据做一些 判断时，例如，EditText的输入数据，假如是简单的非空判断则可以作为View层的逻辑，而当需要对EditText的数据进行更复杂的比较时，如 从数据库获取本地数据进行判断时明显需要经过Model层才能返回了，所以这些细节需要自己掂量。
MVP之Presenter
Presenter这一层处理着程序各种逻辑的分发，收到View层UI上的反馈命令、定时命令、系统命令等指令后分发处理逻辑交由Model层做具体的业务操作。
演示demo
动手写起代码来才有更好的感觉。demo很简单,还是上个图更直观，输入城市的代号，点击按钮获取城市的天气信息然后显示出来，网络操作使用Volley框架，解析用Gson，其它的就手写了。整个项目的包设计如下：
包结构
项目效果预览
包 图中明显的三层：Model包、Presenter包、UI包，其中，三者都实现各自的结构，Model为WeatherModel、Presenter 为WeatherPresenter、View为Weather，那么具体实现类就是impl包里的了，View层的即为Activity。此外的app 和util包无关紧要可以不看。可以看到采用MVP设计后项目明显多了很多东西，这也是不可避免的，使用原始方法可以使项目开起来简单些但是以后还有维护 呢、测试呢、加功能呢、。。。
entity里的实体属性基本上对应json里的这些属性了，代码不贴了，View里面的接口：
- public interface WeatherView {
- void showLoading();
- void hideLoading();
- void showError();
- void setWeatherInfo(Weather weather);
- }
WeatherPresenter的接口：
- public interface WeatherPresenter {
- /**
- * 获取天气的逻辑
- */
- void getWeather(String cityNO);
- }
WeatherModel接口：
- public interface WeatherModel {
- void loadWeather(String cityNO, OnWeatherListener listener);
- }
prestener里面还有个OnWeatherListener，其在Presenter层实现，给Model层回调，更改View层的状态，确保 Model层不直接操作View层。如果没有这一接口在WeatherPresenterImpl实现的话，WeatherPresenterImpl只 有View和Model的引用那么Model怎么把结果告诉View呢？当然这只是一种解决方案，在实际项目中可以使用Dagger、EventBus、 Otto等第三方框架结合进来达到更加松耦合的设计。
- public interface OnWeatherListener {
- /**
- * 成功时回调
- *
- * @param weather
- */
- void onSuccess(Weather weather);
- /**
- * 失败时回调，简单处理，没做什么
- */
- void onError();
- }
所以demo的代码流程：Activity做了一些UI初始化的东西并需要实例化对应WeatherPresenter的引用和实现 WeatherView的接口，监听界面动作，Go按钮按下后即接收到查询天气的事件，在onClick里接收到即通过WeatherPresenter 的引用把它交给WeatherPresenter处理。WeatherPresenter接收到了查询天气的逻辑就知道要查询天气了，然后把查询天气的具 体业务实现交给WeatherModel去实现同时把WeatherListener即WeatherPresenter自己传给 WeatherModel。WeatherModel进行查询天气业务后即把结果通过WeatherListener回调通知 WeatherPresenter，WeatherPresenter再把结果返回给View层的Activity，最后Activity显示结果。就这 样，拍砖之处请拍。
End
采用哪种软件设计模式都是为了达到如下目的，找到合适的加以运用就是最好的：
易于维护
易于测试
松耦合度
复用性高
健壮稳定
本文demo
Rocko’s MVP demo
MVP相关demo
androidmvp
ActivityFragmentMVP
EffectiveAndroidUI
MvpCleanArchitecture
Material-Movies
-
zs1973 . 2016-11-15监听请求结果 只能使用 接口回调么？ 如果我有很多与服务器交互的逻辑，岂不是每个逻辑都要写一个接口哇？有没有好的解决办法呢
-
网友119.4.167.228 . 2016-06-02可以看看网络七层模型，层与层之间就是靠接口通信，接口只是抽象的一种，只管调用方法，不用管实现，接口可以做到细节分离，适合开发的同时进行小鄧子 的原帖：高层不应该知道低层的细节，应该是面向抽象的编程。业务的实现交给实现的接口的类。高层只负责调用。网友218.18.156.254 的原帖：你好我想问一个，你觉得很低级的问题，但是确实一直困扰着我，为什么要定义接口再去实现呢，直接调用方法，不是更加省事？？？接口的好处到底在哪里？？好多地方说是降低耦合，怎么降低了？？确实没有感觉到，希望大神有空的话，指点我一下，我十分感激
-
网友192.240.127.74 . 2016-03-01这是我的理解，不一定完全对！接口主要解决的是行为标准的问题，而继承主要解决的是对象的分类！举个例子，A对象和B对象都要有各自的方法M！按照传统面向对象的做法，可以把M方法放到一个基类base，然后让A、B都继承这个base基类并且各自实现自己的M方法！这样需要使用M方法的地方只需要定义一个基类变量，然后把A、B对象的实例传给这个基类变量，然后调用基类变量的M方法就行了，而不需要关心这个基类变量的实例究竟是A还是B，这就是最传统的面向对象用法了！但是问题来了，其实A和B对象差别非常巨大的，甚至是完全不同的两种东西！如果仅仅因为他们都有M这个方法，就让他们都继承一个基类明显是不合适的，因为这样一方面会增加A、B对象的继承次数，然后也有可能让A、B对象之间的变量方法等发生干扰（谁也无法保证AB的基类永远不发生修改）！所以这时候最佳的做法就是把让A和B对象除了继承自己的基类的同时，也继承一个定义了M这个方法接口类I，这时候需要使用M方法的地方，只需要定义一个接口I的变量，然后把A、B的实例传给这个接口变量，然后大摇大摆的使用方法M而同样不需要关心这个变量究竟是A还是B得实例了！网友218.18.156.254 的原帖：你好我想问一个，你觉得很低级的问题，但是确实一直困扰着我，为什么要定义接口再去实现呢，直接调用方法，不是更加省事？？？接口的好处到底在哪里？？好多地方说是降低耦合，怎么降低了？？确实没有感觉到，希望大神有空的话，指点我一下，我十分感激
-
网友61.148.16.162 . 2016-02-01问题没有高级低级 你问的很好 加油！网友218.18.156.254 的原帖：你好我想问一个，你觉得很低级的问题，但是确实一直困扰着我，为什么要定义接口再去实现呢，直接调用方法，不是更加省事？？？接口的好处到底在哪里？？好多地方说是降低耦合，怎么降低了？？确实没有感觉到，希望大神有空的话，指点我一下，我十分感激
-
小鄧子 . 2016-01-09高层不应该知道低层的细节，应该是面向抽象的编程。业务的实现交给实现的接口的类。高层只负责调用。网友218.18.156.254 的原帖：你好我想问一个，你觉得很低级的问题，但是确实一直困扰着我，为什么要定义接口再去实现呢，直接调用方法，不是更加省事？？？接口的好处到底在哪里？？好多地方说是降低耦合，怎么降低了？？确实没有感觉到，希望大神有空的话，指点我一下，我十分感激
-
泡在网上的日子 . 2016-01-08一个接口定义好，可以被不同的类实现，那样这个类就具有了接口所描述的属性和功能。而且每个类对接口的实现可以完全不一样。 当然你也可以不定义接口，在不同的类中实现彼此之间毫无关联的方法，这完全不会影响程序的性能，但是代码没有逻辑，可读性不好（其实在没有熟悉接口之前，这样可读性对你而言反而更好）。其实这就是一个编程规范的问题。还有就是java中没有多继承，接口却能做到类似多继承的效果。网友218.18.156.254 的原帖：你好我想问一个，你觉得很低级的问题，但是确实一直困扰着我，为什么要定义接口再去实现呢，直接调用方法，不是更加省事？？？接口的好处到底在哪里？？好多地方说是降低耦合，怎么降低了？？确实没有感觉到，希望大神有空的话，指点我一下，我十分感激
-
网友218.18.156.254 . 2016-01-08你好我想问一个，你觉得很低级的问题，但是确实一直困扰着我，为什么要定义接口再去实现呢，直接调用方法，不是更加省事？？？接口的好处到底在哪里？？好多地方说是降低耦合，怎么降低了？？确实没有感觉到，希望大神有空的话，指点我一下，我十分感激
-
网友121.33.48.206 . 2015-11-23github 上的项目的 module 路径变了，，https://github.com/zhengxiaopeng/Rocko-Android-Demos/tree/master/architecture/android-mvplenk 的原帖：Rocko’s MVP demo 又不见了:-)
-
网友118.113.157.124 . 2015-11-23它们github页面的地址经常变，你只能根据错误的地址进入他们的博客中找lenk 的原帖：Rocko’s MVP demo 又不见了:-)
-
lenk . 2015-11-23Rocko’s MVP demo 又不见了:-)
1418
到【灌水乐园】发言
