Android MVP模式 XUtils组合获取数据

MVP(Model-view-present)模式是MVC(Model-view-ccontroller)模式在Android开发上的一种变种,进化模式。

MVC模式

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

Android MVP模式 XUtils组合获取数据_第1张图片

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模式的工作了。
Android MVP模式 XUtils组合获取数据_第2张图片

MVP模式的核心思想:

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

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

MVP模式的作用

1.Activity代码变得更加简洁

2.方便进行单元测试

3,避免内存泄漏


整体功能框架如下图:

Android MVP模式 XUtils组合获取数据_第3张图片

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

Android MVP模式 XUtils组合获取数据_第4张图片

Android MVP模式 XUtils组合获取数据_第5张图片

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


Android MVP模式 XUtils组合获取数据_第6张图片 Android MVP模式 XUtils组合获取数据_第7张图片

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

Android MVP模式 XUtils组合获取数据_第8张图片 Android MVP模式 XUtils组合获取数据_第9张图片 Android MVP模式 XUtils组合获取数据_第10张图片 Android MVP模式 XUtils组合获取数据_第11张图片


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

你可能感兴趣的:(设计模式)