MVP 框架模式（学习笔记）

总结了MVC框架模式后，现在来总结下MVP 框架模式。
为了更细分视图（View）与模型（Model）的功能，让View更加专注于处理数据的可视化以及用户的交互，同时让Model只负责数据的处理，也就有了基于MVC概念的MVP(Model-View-Presenter)模式。

上图是理解MVP框架模式的最好图例了。

现在根据上图简单介绍下几个元素：

• View:
  主要负责绘制UI元素、与用户进行交互， Activity 处于MVP框架模式的V层，负责与用户界面互动 Activity通过接口与Presenter（可以理解为真正的指挥者）进行互动这样可以降低耦合。

• View interface:
  需要View（安卓中为Activity）实现的接口，通过View interface 与 Presenter进行交互，降低耦合，方便单元测试。

• Model:
  负责数据的存储、检索、操作。常实现一个 Model interface 来减低耦合

• Presenter:
  作为 View 层 与 Model 层 交互的中间媒介（纽带）负责处理用户交互的复杂逻辑。实际上相当于指挥者。

使用MVP模式在安卓中

• 在Android开发中，Activity并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始化用户界面，并接受和处理来自用户的操作请求，进而作出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。当我们将其中复杂的逻辑处理移至另外的一个类（Presneter）中时，Activity其实就是MVP模式中View，它负责UI元素的初始化，建立UI元素与Presenter的关联（Listener之类），同时自己也会处理一些简单的逻辑（复杂的逻辑交由Presenter处理）.
• 另外，回想一下在开发Android应用时是如何对代码逻辑进行单元测试的？是否每次都要将应用部署到Android模拟器或真机上，然后通过模拟用户操作进行测试？然而由于Android平台的特性，每次部署都耗费了大量的时间，这直接导致开发效率的降低。而在MVP模式中，处理复杂逻辑的Presenter是通过interface与View(Activity)进行交互的，这说明了什么？说明我们可以通过自定义类实现这个interface来模拟Activity的行为对Presenter进行单元测试，省去了大量的部署及测试的时间。

MVP&MVC

 MVC模式与MVP模式都作为用来分离UI层与业务层的一种开发模式，在我们选择一种开发模式时，首先需要了解一下这种模式的利弊：
 无论MVC或是MVP模式都不可避免地存在一个弊端：

额外的代码复杂度及学习成本，这就导致了这两种开发模式也许并不是很小型应用。
但比起他们的优点，这点弊端基本可以忽略了：
(1)降低耦合度
(2)模块职责划分明显
(3)利于测试驱动开发
(4)代码复用
(5)隐藏数据
(6)代码灵活性

• MVP模式：
  View不直接与Model交互，而是通过与Presenter交互来与Model间接交互
  Presenter与View的交互是通过接口来进行的，更有利于添加单元测试
  通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑
• MVC模式：
  View可以与Model直接交互
  Controller是基于行为的，并且可以被多个View共享
  可以负责决定显示哪个View

放在github上的demo
备注详细易懂，欢迎 star一下
A simple demo for MVP

喝水不忘挖井人：
本文观点参考文章