Android MVP模式 XUtils组合获取数据

MVP（Model-view-present）模式是MVC（Model-view-ccontroller）模式在Android开发上的一种变种，进化模式。

MVC模式

MVC模式的结构分为三部分，实体类的Model，视图类的View ，以及控制层的controller。

1.其中View层就是程序的UI界面，用于向用户展示数据以及接受用的话输入，及程序的Activity。

2.Model层就是JavaBean实体类，用于保存实例数据。

3.Controller控制器用于更新UI界面跟数据实例。

例如：View层接受用户的输入，然后通过Controller修改对应的Model实例，同时当model实例的数据发生变化时，需要修改UI界面，可以通过Controller更新界面。（View层也可以直接更新Mode，这样对于一些简单的数据更新工作会方便许多，例如观察者模式）。

MVP模式

按照MVC的分层，Activity和Fragment（后面只说Activity）应该属于View层，用于展示UI界面，以及接收用户的输入，此外还要承担一些生命周期的工作。Activity是在Android开发中充当非常重要的角色，特别是TA的生命周期的功能，所以开发的时候我们经常把一些业务逻辑直接写在Activity里面，这非常直观方便，代价就是Activity会越来越臃肿，超过1000行代码是常有的事，而且如果是一些可以通用的业务逻辑（比如用户登录），写在具体的Activity里就意味着这个逻辑不能复用了。如果有进行代码重构经验的人，看到1000+行的类肯定会有所顾虑。因此，Activity不仅承担了View的角色，还承担了一部分的Controller角色，这样一来V和C就耦合在一起了，虽然这样写方便，但是如果业务调整的话，要维护起来就难了，而且在一个臃肿的Activity类查找业务逻辑的代码也会非常蛋疼，所以看起来有必要在Activity中，把View和Controller抽离开来，而这就是MVP模式的工作了。

MVP模式的核心思想：

MVP把Activity的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。

这就是MVP模式，现在这样的话，Activity的工作的简单了，只用来响应生命周期，其他工作都丢到Presenter中去完成。从上图可以看出，Presenter是Model和View之间的桥梁，为了让结构变得更加简单，View并不能直接对Model进行操作，这也是MVP与MVC最大的不同之处。

MVP模式的作用

1.Activity代码变得更加简洁

2.方便进行单元测试

3,避免内存泄漏

整体功能框架如下图：

View层负责界面的更新和展示

model层：主要负责数据的处理，将数据返回给presenter层，presenter层再将数据返回给view层

presenter层：起承接作用，帮view层拿到对应的数据

参考：http://blog.csdn.net/qq_16666847/article/details/53224426

http://blog.csdn.net/qq_27630169/article/details/52176742