Android开发MVP模式解析

http://www.cnblogs.com/bravestarrhu/archive/2012/05/02/2479461.html

在开发Android应用时，相信不少同窗遇到和我同样的状况，虽然项目刚开始构架时自认为MVC层级分的特别明确，但最终每每是一个Activity有好几百行代码，并且逻辑和UI显示彻底混杂在一块儿，致使后续项目的维护成本巨大。一个偶然的机会看到有种MVP模式（Mode-View-Presenter）能够比MVC更好的解耦和，而后好奇的研究了下这个模式并尝试在如今项目中进行推广。下面就把本身目前学习到知识总结出来。

MVP模式将分为两篇博客进行总结：

（一）Android开发MVP模式解析

（二）Android开发MVP模式实践

1、MVP简介

我理解的MVP是由MVC优化衍生出来的一种模式，MVP将MVC中的Controller层进行了优化而生成了Presenter。Presenter单词翻译为“提出者；任命者；主持人”，Presenter层和MVC的Controller同样，负责核心逻辑，但不同的是Presenter经过接口协议进行数据传递，并阻断了View和Model的直接联系，从而使View和Model更加专一于自身业务逻辑。

2、MVP结构

View

View一般来讲就是有Activity、Fragment实现的，View会包含一个或多个Presenter的引用来知足视图的业务逻辑。View和Presenter的交互是双向的，即View层能够调用Presenter的逻辑方法，Presenter也能够控制View的显示。

Presenter

Presenter做为Model和View的桥梁，负责从Model拿到数据进行处理并返回给View。但Presenter和其余两层的沟通是经过接口协议进行的，因此每一个Presenter中一般会包涵一个或多个接口协议。

Model

和MVC同样，做为数据仓库只负责对APP数据进行处理。

Android开发MVP模式实践中的示例将APP分为如下四层。

 

• Entities:APP中的业务类。
• Use Cases:负责从将Entities中的数据进行处理和包装。
• Presenters:从Use Cases获取处理好的数据，而后根据需求逻辑为UI提供合适的数据。
• UI:从Presenters获取处理好的最终数据，和用户进行直接交互。

这四层设计的原则是代码调用只能从外圆向内圆扩展，内圆不能干预也不需关心外圆的功能逻辑，这符合MVP的思想，Use Cases和Presenters将Entities和UI间隔分离，从而使Entities和UI只需关心自身逻辑，数据处理彻底交给其余两层。

这里，有些同窗可能会有疑问，说好的Presenters为何会有Use Cases出来搅局？其实这也是我选择这个工程当作示例的目的，看了好多MVP文章，都在讲Presenter如何经过接口协议和其余两层进行交互，但大都忽略了Presenter层自身的构架，由于仅仅套用MVP模式，虽然在必定程度上下降View的耦合度，但由于Presenter既要处理数据，又要结合需求控制UI交互，因此极可能出现Presenter逻辑的冗余。后文的示例工程在Presenter和Model之间包装了Use Cases，将数据逻辑处理交给UseCases从而让Presenter更专心于UI交互。

 

3、MVP VS MVC

在把本来MVC模式的代码修改成MVP模式后，总结这两个模式在实际使用过程当中的不一样点基本上总结为两点：

 

• 各个层之间经过接口协议进行沟通；
• View和Model再也不进行直接交互；

详细说明请参考 MVC or MVP Pattern - Whats the difference?

 

4、总结

MVP将会为你的代码带来以下好处：

 

• View和Model之间的耦合度下降，使其更关注自身业务逻辑；
• 便于单元测试；
• 代码复用率提升；
• 代码框架更适用于快速迭代开发；

参考资料：

Android上的MVP模式

MVC or MVP Pattern - Whats the difference?

Architecting Android...The Clean way?