响应式MVP架构todo-mvp-rxjava实践

很多时候，Activity可能既承担UI显示工作，又承担部分业务逻辑工作，甚至是各种网络请求、回调等，这样的话Activity的代码会快速膨胀，有时候我们可以看到几千行代码的Activity。一个到这样的类就是比较痛苦的事情。那用什么办法解决呢？

现在基本是采取横向切割细分或者纵向层次化：

第一种是模块化
第二种是分层

两个方法最终要实现的都是解耦。分层讲的是纵向层面上的解耦，模块化则是横向上的解耦。

MVP-RxJava

现在让我们来实践一下Google官方提供的MVP-RxJava。

MVP架构中将这三层分别抽象到各自的接口当中，从而通过分层来进行解耦的框架。通过接口将层次之间进行隔离，而Presenter对View和Model的相互依赖也是依赖于各自的接口。这点符合了接口隔离原则，也正是面向接口编程。每个类都尽量符合面向对象设计原则，采用单一职责原则，以便整个项目架构清晰分工明确。

Google提供的Android官方MVP整个项目的逻辑图如下：

使用这样的架构有一个最大的好处就是解耦，view就只负责更新UI，显示控件，完成与用户的交互；model的职责呢就是去加载数据；具体的model什么时候去获取数据，获取完了之后ui什么时候去更新，这一切都是由presenter去完成。这样做，一方面适合团队协作去开发，另一方面也方便测试，各个模块之间互不干扰。

我们知道，在Android中异步操作一般使用AsycTask来完成，但是AsycTask有很多缺点，如不能方便的终止任务的执行等。

RxAndroid是一个在 Java VM 上使用可观测的序列来组成异步的、基于事件的程序的库，它完全可以替代AsycTask来完成各种异步操作，而且还有BindActivity和BindFragment方法，你根本不需要考虑异步操作时的Activity和Fragment的生命周期问题。

异步操作很关键的一点是程序的简洁性，因为在调度过程比较复杂的情况下，异步代码经常会既难写也难被读懂。 Android 创造的AsyncTask 和Handler ，其实都是为了让异步代码更加简洁。RxJava 的优势也是简洁，但它的简洁的与众不同之处在于，随着程序逻辑变得越来越复杂，它依然能够保持简洁。

经过技术选型、程序结构设计，再结合上面列举的架构设计优点，我们可以在项目中用下面的架构进行设计实现，即MVP+RxJava+Realm的模式。

其中网络层使用了OkHttp，通过响应式的RxJava与Presenter交互，再由Presenter与界面交互，实现解藕；数据库则选择了性能更高、编程更简洁优雅的Realm，它与RxJava配合使用也更方便快捷。

模式比较

MVP 与 MVC

对于原生的Android项目来说，layout.xml里面的xml文件就对应于MVC的view层
当用户出发事件的时候，view层会发送指令到controller层，接着controller去通知model层更新数据，model层更新完数据以后直接显示在view层上，这就是MVC的工作原理。
MVP中把Layout布局和Activity作为View层，增加了Presenter，Presenter层与Model层进行业务的交互，完成后再与View层交互（也就是Activity）进行回调来刷新UI
在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部

优缺点

MVC

优点：

首先就是理解比较容易，技术含量不高，这对开发和维护来说成本较低也易于维护与修改。
耦合性不高，表现层与业务层分离各司其职，对开发来说很有利。

缺点：

Controller对应的是Activity，而Activity中却又具有操作UI的功能，Activity所在的Controller是非常重的，各层次之间的耦合情况也比较严重，不方便单元测试。
MVC 没有完全解耦，view层和model层是相互可知的。

MVP

优点：

与MVC最明显的差别就是view层和model层不再相互可知，完全的解耦。
方便测试驱动开发。
代码复用度较高。

MVP 与 MVVM

与MVVM（Model-View-ViewModel）的区别：

MVVM与MVP非常相似，唯一区别是View和Model进行双向绑定，两者之间有一方发生变化则会反应到另一方上。MVVM模式有点像ListView与Adapter、数据集的关系，当数据集发生变化时，调用Adapter的notifyDataSetChanged之后View就直接更新，同时它们之间又没有耦合，使得ListView变得更加灵活。

ngudream