MVC、MVP、MVVM 模式（待续）

 

本文将从收集来的资料整理分析MVC模型的各种应用以及其演化历程

一、 介绍 MV* 模式

MVC、MVP、MVVM 模式都是为了解决图形界面应用程序复杂性管理问题而产生的应用架构模式。追根溯源，从最经典的Smalltalk-80 MVC模式开始逐步还原图形界面之下最真实的MV*模式。

GUI程序所面临的问题

图形界面的应用程序提供给用户可视化的操作界面，这个界面提供给数据和信息。用户输入行为（键盘，鼠标等）会执行一些业务逻辑，可能会导致对应用程序数据的变更，数据的变更自然需要用户界面的同步变更以提供最准确的信息。例如用户对一个电子表格重新排序的操作，应用程序需要响应用户操作，对数据进行排序，然后需要同步到界面上。

在开发应用程序的时候，以求更好的管理应用程序的复杂性，基于职责分离（Speration of Duties）的思想都会对应用程序进行分层。在开发图形界面应用程序的时候，会把管理用户界面的层次称为View，应用程序的数据为Model（注意这里的Model指的是Domain Model，这个应用程序对需要解决的问题的数据抽象，不包含应用的状态，可以简单理解为对象）。Model层对应用程序的业务逻辑无知，只保存数据结构和提供数据操作的接口。

有了View和Model的分层，那么就有了两个问题：

  1. 响应用户操作的业务逻辑（例如排序）的管理。
  2. View如何同步Model的变更。

带着这两个问题开始探索MV*模式，会发现这些模式之间的差异可以归纳为对这两个问题处理的方式的不同。而几乎所有的MV*模式都是经典的Smalltalk-80 MVC的修改版。

Smalltalk-80 MVC

历史背景

早在上个世纪70年代，美国的施乐公司（Xerox）的工程师研发了Smalltalk编程语言，并且开始用它编写图形界面的应用程序。而在Smalltalk-80这个版本的时候，一位叫Trygve Reenskaug的工程师设计了MVC图形应用程序的架构模式，极大地降低了图形应用程序的管理难度。而在四人众（GoF）的设计模式当中并没有把MVC当做是设计模式，而仅仅是把它看成解决问题的一些类的集合。Smalltalk-80 MVC和GoF描述的MVC是最经典的MVC模式。

 

MVC的依赖关系

MVC出了把应用程序分成View、Model层，还额外的加了一个Controller层，它的职责就是专门管理应用程序的业务逻辑。Model、View、Controller三个层次的依赖关系如下：

Controller和View都依赖Model层，Controller和View可以互相依赖。在一些网上的资料Controller和View之间的依赖关系可能不一样，有些是单向依赖，有些是双向依赖，这个其实关系不大，后面会看到它们的依赖关系都是为了把处理用户行为触发的业务逻辑的处理权交给Controller。

MVC的调用关系

用户的对View操作以后，View捕获到这个操作，会把处理的权利交移给Controller（Pass calls）；Controller接着会执行相关的业务逻辑，这些业务逻辑可能需要对Model进行相应的操作；当Model变更了以后，会通过观察者模式（Observer Pattern）通知View；View通过观察者模式收到Model变更的消息以后，会向Model请求最新的数据，然后重新更新界面。如下图：

看似没有什么特别的地方，但是由几个需要特别关注的关键点：

  1. View是把控制权交移给Controller，自己不执行业务逻辑。
  2. Controller执行业务逻辑并且操作Model，但不会直接操作View，可以说它是对View无知的。
  3. View和Model的同步消息是通过观察者模式进行，而同步操作是由View自己请求Model的数据然后对视图进行更新。

需要特别注意的是MVC模式的精髓在于第三点：Model的更新是通过观察者模式告知View的，具体表现形式可以是Pub/Sub或者是触发Events。而网上很多对于MVC的描述都没有强调这一点。通过观察者模式的好处就是：不同的MVC三角关系可能会有共同的Model，一个MVC三角中的Controller操作了Model以后，两个MVC三角的View都会接受到通知，然后更新自己。保持了依赖同一块Model的不同View显示数据的实时性和准确性。我们每天都在用的观察者模式，在几十年前就已经被大神们整合到MVC的架构当中。

这里有一个MVC模式的JavaScript Demo，实现了一个小的TodoList应用程序。经典的Smalltalk-80 MVC不需要任何框架支持就可以实现。目前Web前端框架当中只有一个号称是严格遵循Smalltalk-80 MVC模式的：maria.js。

MVC的优缺点

优点：

  1. 把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了（Swappable Controller）。
  2. 观察者模式可以做到多视图同时更新。

缺点：

  1. Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。
  2. View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的

MVC Model 2

在Web服务端开发的时候也会接触到MVC模式，而这种MVC模式不能严格称为MVC模式。经典的MVC模式只是解决客户端图形界面应用程序的问题，而对服务端无效。服务端的MVC模式又自己特定的名字：MVC Model 2，或者叫JSP Model 2，或者直接就是Model 2 。Model 2客户端服务端的交互模式如下：

服务端接收到来自客户端的请求，服务端通过路由规则把这个请求交由给特定的Controller进行处理，Controller执行相应的业务逻辑，对数据库数据（Model）进行操作，然后用数据去渲染特定的模版，返回给客户端。

因为HTTP协议是单工协议并且是无状态的，服务器无法直接给客户端推送数据。除非客户端再次发起请求，否则服务器端的Model的变更就无法告知客户端。所以可以看到经典的Smalltalk-80 MVC中Model通过观察者模式告知View更新这一环被无情地打破，不能称为严格的MVC。

Model 2模式最早在1998年应用在JSP应用程序当中，JSP Model 1应用管理的混乱诱发了JSP参考了客户端MVC模式，催生了Model 2。

后来这种模式几乎被应用在所有语言的Web开发框架当中。PHP的ThinkPHP，Python的Dijango、Flask，NodeJS的Express，Ruby的RoR，基本都采纳了这种模式。平常所讲的MVC基本是这种服务端的MVC。

MVP

MVP模式有两种：

  1. Passive View
  2. Supervising Controller

而大多数情况下讨论的都是Passive View模式。本文会对PV模式进行较为详细的介绍，而SC模式则简单提及。

历史背景

MVP模式是MVC模式的改良。在上个世纪90年代，IBM旗下的子公司Taligent在用C/C++开发一个叫CommonPoint的图形界面应用系统的时候提出来的。

MVP（Passive View）的依赖关系

MVP模式把MVC模式中的Controller换成了Presenter。MVP层次之间的依赖关系如下：

MVP打破了View原来对于Model的依赖，其余的依赖关系和MVC模式一致。

MVP（Passive View）的调用关系

既然View对Model的依赖被打破了，那View如何同步Model的变更？看看MVP的调用关系：

和MVC模式一样，用户对View的操作都会从View交移给Presenter。Presenter同样的会执行相应的业务逻辑，并且对Model进行相应的操作；而这时候Model也是通过观察者模式把自己变更的消息传递出去，但是是传给Presenter而不是View。Presenter获取到Model变更的消息以后，通过View提供的接口更新界面。

关键点：

  1. View不再负责同步的逻辑，而是由Presenter负责。Presenter中既有业务逻辑也有同步逻辑。
  2. View需要提供操作界面的接口给Presenter进行调用。（关键）

对比在MVC中，Controller是不能操作View的，View也没有提供相应的接口；而在MVP当中，Presenter可以操作View，View需要提供一组对界面操作的接口给Presenter进行调用；Model仍然通过事件广播自己的变更，但由Presenter监听而不是View。

MVP模式，这里也提供一个用JavaScript编写的例子。

MVP（Passive View）的优缺点

优点：

  1. 便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。这里根据上面的例子给出了Presenter的单元测试样例。
  2. View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。

缺点：

  1. Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来��比较困难。

MVP（Supervising Controller）

上面讲的是MVP的Passive View模式，该模式下View非常Passive，它几乎什么都不知道，Presenter让它干什么它就干什么。而Supervising Controller模式中，Presenter会把一部分简单的同步逻辑交给View自己去做，Presenter只负责比较复杂的、高层次的UI操作，所以可以把它看成一个Supervising Controller。

Supervising Controller模式下的依赖和调用关系：

因为Supervising Controller用得比较少，对它的讨论就到这里为止。

MVVM

MVVM可以看作是一种特殊的MVP（Passive View）模式，或者说是对MVP模式的一种改良。

历史背景

MVVM模式最早是微软公司提出，并且了大量使用在.NET的WPF和Sliverlight中。2005年微软工程师John Gossman在自己的博客上首次公布了MVVM模式。

ViewModel

MVVM代表的是Model-View-ViewModel，这里需要解释一下什么是ViewModel。ViewModel的含义就是 "Model of View"，视图的模型。它的含义包含了领域模型（Domain Model）和视图的状态（State）。 在图形界面应用程序当中，界面所提供的信息可能不仅仅包含应用程序的领域模型。还可能包含一些领域模型不包含的视图状态，例如电子表格程序上需要显示当前排序的状态是顺序的还是逆序的，而这是Domain Model所不包含的，但也是需要显示的信息。

可以简单把ViewModel理解为页面上所显示内容的数据抽象，和Domain Model不一样，ViewModel更适合用来描述View。

MVVM的依赖

MVVM的依赖关系和MVP依赖，只不过是把P换成了VM。

MVVM的调用关系

MVVM的调用关系和MVP一样。但是，在ViewModel当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。你只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去，当用户对View进行操作（例如表单输入），Binder也会自动把数据更新到Model上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地理解为一个模版引擎，但是会根据数据变更实时渲染。

也就是说，MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作，而是交由框架所提供的Binder进行负责。只需要告诉Binder，View显示的数据对应的是Model哪一部分即可。

这里有一个JavaScript MVVM的例子，因为MVVM需要Binder引擎。所以例子中使用了一个MVVM的库：Vue.js。

MVVM的优缺点

优点：

  1. 提高可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。
  2. 简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。

缺点：

  1. 过于简单的图形界面不适用，或说牛刀杀鸡。
  2. 对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。
  3. 数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。

总结

可以看到，从MVC->MVP->MVVM，就像一个打怪升级的过程。后者解决了前者遗留的问题，把前者的缺点优化成了优点。同样的Demo功能，代码从最开始的一堆文件，优化成了最后只需要20几行代码就完成。MV*模式之间的区分还是蛮清晰的，希望可以给对这些模式理解比较模糊的同学带来一些参考和思路。

 

二、Web MVC简介

1.1、Web开发中的请求-响应模型：

 

 

在Web世界里，具体步骤如下：

1、  Web浏览器（如IE）发起请求，如访问百度

2、  Web服务器（如Tomcat）接收请求，处理请求（比如用户新增，则将把用户保存一下），最后产生响应（一般为html）。

3、web服务器处理完成后，返回内容给web客户端（一般就是我们的浏览器），客户端对接收的内容进行处理（如web浏览器将会对接收到的html内容进行渲染以展示给客户）。

 

因此，在Web世界里：

都是Web客户端发起请求，Web服务器接收、处理并产生响应。

 

一般Web服务器是不能主动通知Web客户端更新内容。虽然现在有些技术如服务器推（如Comet）、还有现在的HTML5 websocket可以实现Web服务器主动通知Web客户端。

 

到此我们了解了在web开发时的请求/响应模型，接下来我们看一下标准的MVC模型是什么。

 

1.2、标准MVC模型概述

MVC模型：是一种架构型的模式，本身不引入新功能，只是帮助我们将开发的结构组织的更加合理，使展示与模型分离、流程控制逻辑、业务逻辑调用与展示逻辑分离。如图1-2

 

 

图1-2

首先让我们了解下MVC（Model-View-Controller）三元组的概念：

Model（模型）：数据模型，提供要展示的数据，因此包含数据和行为，可以认为是领域模型或JavaBean组件（包含数据和行为），不过现在一般都分离开来：Value Object（数据） 和 服务层（行为）。也就是模型提供了模型数据查询和模型数据的状态更新等功能，包括数据和业务。

 

View（视图）：负责进行模型的展示，一般就是我们见到的用户界面，客户想看到的东西。

 

Controller（控制器）：接收用户请求，委托给模型进行处理（状态改变），处理完毕后把返回的模型数据返回给视图，由视图负责展示。 也就是说控制器做了个调度员的工作，。

 

从图1-1我们还看到，在标准的MVC中模型能主动推数据给视图进行更新（观察者设计模式，在模型上注册视图，当模型更新时自动更新视图），但在Web开发中模型是无法主动推给视图（无法主动更新用户界面），因为在Web开发是请求-响应模型。

 

那接下来我们看一下在Web里MVC是什么样子，我们称其为 Web MVC 来区别标准的MVC。

1.3、Web MVC概述

模型-视图-控制器概念和标准MVC概念一样，请参考1.2，我们再看一下Web MVC标准架构，如图1-3：

 

如图1-3

 

在Web MVC模式下，模型无法主动推数据给视图，如果用户想要视图更新，需要再发送一次请求（即请求-响应模型）。

 

概念差不多了，我们接下来了解下Web端开发的发展历程，和使用代码来演示一下Web MVC是如何实现的，还有为什么要使用MVC这个模式呢？

 

1.4、Web端开发发展历程

此处我们只是简单的叙述比较核心的历程，如图1-4

 

 

图1-4

1.4.1、CGI：（Common Gateway Interface）公共网关接口，一种在web服务端使用的脚本技术，使用C或Perl语言编写，用于接收web用户请求并处理，最后动态产生响应给用户，但每次请求将产生一个进程，重量级。

 

1.4.2、Servlet：一种JavaEE web组件技术，是一种在服务器端执行的web组件，用于接收web用户请求并处理，最后动态产生响应给用户。但每次请求只产生一个线程（而且有线程池），轻量级。而且能利用许多JavaEE技术（如JDBC等）。本质就是在java代码里面 输出 html流。但表现逻辑、控制逻辑、业务逻辑调用混杂。如图1-5    

 

图1-5

如图1-5，这种做法是绝对不可取的，控制逻辑、表现代码、业务逻辑对象调用混杂在一起，最大的问题是直接在Java代码里面输出Html，这样前端开发人员无法进行页面风格等的设计与修改，即使修改也是很麻烦，因此实际项目这种做法不可取。

 

1.4.3、JSP：（Java Server Page）：一种在服务器端执行的web组件，是一种运行在标准的HTML页面中嵌入脚本语言（现在只支持Java）的模板页面技术。本质就是在html代码中嵌入java代码。JSP最终还是会被编译为Servlet，只不过比纯Servlet开发页面更简单、方便。但表现逻辑、控制逻辑、业务逻辑调用还是混杂。如图1-6

 

 

 

图1-6

 

如图1-6，这种做法也是绝对不可取的，控制逻辑、表现代码、业务逻辑对象调用混杂在一起，但比直接在servlet里输出html要好一点，前端开发人员可以进行简单的页面风格等的设计与修改（但如果嵌入的java脚本太多也是很难修改的），因此实际项目这种做法不可取。

 

 

JSP本质还是Servlet，最终在运行时会生成一个Servlet（如tomcat，将在tomcat\work\Catalina\web应用名\org\apache\jsp下生成），但这种使得写html简单点，但仍是控制逻辑、表现代码、业务逻辑对象调用混杂在一起。

 

1.4.4、Model1：可以认为是JSP的增强版，可以认为是jsp+javabean如图1-7

特点：使用<jsp:useBean>标准动作，自动将请求参数封装为JavaBean组件；还必须使用java脚本执行控制逻辑。

 

 

 

图1-7

此处我们可以看出，使用<jsp:useBean>标准动作可以简化javabean的获取/创建，及将请求参数封装到javabean，再看一下Model1架构，如图1-8。

 

 

图1-8 Model1架构

Model1架构中，JSP负责控制逻辑、表现逻辑、业务对象（javabean）的调用，只是比纯JSP简化了获取请求参数和封装请求参数。同样是不好的，在项目中应该严禁使用（或最多再demo里使用）。

 

1.4.5、Model2：在JavaEE世界里，它可以认为就是Web MVC模型

Model2架构其实可以认为就是我们所说的Web MVC模型，只是控制器采用Servlet、模型采用JavaBean、视图采用JSP，如图1-9

 

 

图1-9 Model2架构

 

具体代码事例如下：

 

 

 

 

 

从Model2架构可以看出，视图和模型分离了，控制逻辑和展示逻辑分离了。

但我们也看到严重的缺点：

1．  1、控制器：

1．1．1、控制逻辑可能比较复杂，其实我们可以按照规约，如请求参数submitFlag=toAdd，我们其实可以直接调用toAdd方法，来简化控制逻辑；而且每个模块基本需要一个控制器，造成控制逻辑可能很复杂；

1．1．2、请求参数到模型的封装比较麻烦，如果能交给框架来做这件事情，我们可以从中得到解放；

1．1．3、选择下一个视图，严重依赖Servlet API，这样很难或基本不可能更换视图；

1．1．4、给视图传输要展示的模型数据，使用Servlet API，更换视图技术也要一起更换，很麻烦。

 

1.2、模型：

1．2．1、此处模型使用JavaBean，可能造成JavaBean组件类很庞大，一般现在项目都是采用三层架构，而不采用JavaBean。

 

 

 

1.3、视图

1．3．1、现在被绑定在JSP，很难更换视图，比如Velocity、FreeMarker；比如我要支持Excel、PDF视图等等。

 

1.4.5、服务到工作者：Front Controller + Application Controller + Page Controller + Context

即，前端控制器+应用控制器+页面控制器（也有称其为动作）+上下文，也是Web MVC，只是责任更加明确，详情请参考《核心J2EE设计模式》和《企业应用架构模式》如图1-10：

 

 

图1-10

运行流程如下：

 

 

职责：

Front Controller：前端控制器，负责为表现层提供统一访问点，从而避免Model2中出现的重复的控制逻辑（由前端控制器统一回调相应的功能方法，如前边的根据submitFlag=login转调login方法）；并且可以为多个请求提供共用的逻辑（如准备上下文等等），将选择具体视图和具体的功能处理（如login里边封装请求参数到模型，并调用业务逻辑对象）分离。

 

Application Controller：应用控制器，前端控制器分离选择具体视图和具体的功能处理之后，需要有人来管理，应用控制器就是用来选择具体视图技术（视图的管理）和具体的功能处理（页面控制器/命令对象/动作管理），一种策略设计模式的应用，可以很容易的切换视图/页面控制器，相互不产生影响。

 

Page Controller(Command)：页面控制器/动作/处理器：功能处理代码，收集参数、封装参数到模型，转调业务对象处理模型，返回逻辑视图名交给前端控制器（和具体的视图技术解耦），由前端控制器委托给应用控制器选择具体的视图来展示，可以是命令设计模式的实现。页面控制器也被称为处理器或动作。

 

Context：上下文，还记得Model2中为视图准备要展示的模型数据吗，我们直接放在request中（Servlet API相关），有了上下文之后，我们就可以将相关数据放置在上下文，从而与协议无关（如Servlet API）的访问/设置模型数据，一般通过ThreadLocal模式实现。

 

 

到此，我们回顾了整个web开发架构的发展历程，可能不同的web层框架在细节处理方面不同，但的目的是一样的：

干净的web表现层：

    模型和视图的分离；

控制器中的控制逻辑与功能处理分离（收集并封装参数到模型对象、业务对象调用）；

控制器中的视图选择与具体视图技术分离。

轻薄的web表现层：

    做的事情越少越好，薄薄的，不应该包含无关代码；

       只负责收集并组织参数到模型对象，启动业务对象的调用；

       控制器只返回逻辑视图名并由相应的应用控制器来选择具体使用的视图策略；

       尽量少使用框架特定API，保证容易测试。

 

到此我们了解Web MVC的发展历程，接下来让我们了解下Spring MVC到底是什么、架构及来个HelloWorld了解下具体怎么使用吧。

 

本章具体代码请参考 springmvc-chapter1工程。

 

三、MVC和MVP在app中的对比分析以及实际应用

为了解决逻辑处理和UI视图的松散耦合，MVC和MVP的架构模式在很多App中使用比较广泛。

那什么是MVP呢？它又和我们常常听到的MVC有什么关系了以及区别呢？

MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负 责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是 View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

MVP如何解决MVC的问题？

在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具 体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！ 不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试—而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。 在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。因此就有人提出了Presenter First的设计模式，就是根据User Story来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。在后面，根据需要再随便更改View， 而对Presenter没有任何的影响了。 如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系，就可以在View和Presenter之间放置一个Adapter。由这个 Adapter来访问Model和View，避免两者之间的关联。而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之 间接口的不变。这样就可以保证View和Presenter之间接口的简洁，又不失去UI的灵活性。 在MVP模式里，View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接访问Model— 这就是与MVC很大的不同之处。

MVP的优点：

1、模型与视图完全分离，我们可以修改视图而不影响模型；
2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

使用方法

1、建立bean

public class UserBean {

    private String mFirstName;

    private String mLastName;

    public UserBean(String firstName, String lastName) {

        this. mFirstName = firstName;

        this. mLastName = lastName;

    }

    public String getFirstName() {

        return mFirstName;

    }

    public String getLastName() {

        return mLastName;

    }

}

 

 

2、建立model接口（处理业务逻辑，这里指数据读写）

public interface IUserModel {

    void setID(int id);

    void setFirstName(String firstName);

    void setLastName(String lastName);

    int getID();

    UserBean load(int id);// 通过id读取user信息,返回一个UserBean

}

 

 

3、建立view接口（更新ui中的view状态），这里列出需要操作当前view的方法

public interface IUserView {

    int getID();

    String getFristName();

    String getLastName();

    void setFirstName(String firstName);

    void setLastName(String lastName);

}

 

 

4、建立presenter（主导器，通过iView和iModel接口操作model和view），activity可以把所有逻辑给presenter处理，这样java逻辑就从手机的activity中分离出来

public class UserPresenter {

    private IUserView mUserView;

    private IUserModel mUserModel;

    public UserPresenter(IUserView view) {

        mUserView = view;

        mUserModel = new UserModel();

    }

    public void saveUser( int id, String firstName, String lastName) {

        mUserModel.setID(id);

        mUserModel.setFirstName(firstName);

        mUserModel.setLastName(lastName);

    }

    public void loadUser( int id) {

        UserBean user = mUserModel.load(id);

        mUserView.setFirstName(user.getFirstName()); // 通过调用IUserView的方法来更新显示

        mUserView.setLastName(user.getLastName());

    }

}

 

 

结束语

MVP主要解决就是把逻辑层抽出来成P层，要是遇到需求逻辑上的更改就可以只需要修改P层了或者遇到逻辑上的大概我们可以直接从写一个P也可以，很 多开发人员把所有的东西都写在了Activity/Fragment里面这样一来遇到频繁改需求或者逻辑越来越复杂的时候，Activity /Fragment里面就会出现过多的混杂逻辑导致出错，所以MVP模式对于APP来对控制逻辑和UI的解耦来说是一个不错的选择！

 

四、MVP模式

 

一个简单的发送内容的demo 先上效果图

 




 

MVP模式的结构

 

 

 

 

1、什么是MVP模式？

 

    分离view 与 model 层的功能，使得程序更加清晰 提高分离 解耦性，减轻activity的工作量 将业务代码单独抽取出来，各自负责各自层应该做的事情。简单一句话说就是基于MVC模式演变而来，提高代码结构清晰度，提高程序解耦性可维护性的模式。

 

    接下来我们具体梳理下MVP究竟是什么

 

    M 对应的Model 数据层，负责操作、获取数据

 

    V 对应的是View 也就是Activity层，负责UI、与用户进行交互

 

    P Presenter 就是我们要分离的业务逻辑层，连接view和model层，处理业务逻辑。

 

 

 

2、为什么要用MVP模式？

 

    Android开发不同于JavaWeb开发的是利用MVC模式 使得控制器和展示层完全分离，但是Android中activity有控制器也有view做的事情，如果把布局文件单独分成view层，几乎就没有做什么事情，而activity还承担了部分view层的工作，到最后需求越来越多，activity也会越来也胖。所以在Android开发中可以使用MVP模式来清晰的分离各自层的工作。同样也利于单元测试。

 

 

 

3、MVP模式怎么用？

 

    view层专门负责UI及用户交互

 

    Persenter层负责所有的业务逻辑的处理

 

    Model层负责数据的获取、操纵

 

    各个层单独分离，用层与层之间用接口交互

 

下面我们来看一个简单的Demo

 

    Acitivity  也就是view层 实现了ViewInterface接口，分离业务逻辑

 

public class MainActivity extends AppCompatActivity implements ViewInterface, View.OnClickListener {


private EditText content;
private EditText author;
private Button send;
private Button clean;
private ProgressBar loading;

private PresenterImpl presenter;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
initView();
}
public void initView(){
content = (EditText) findViewById(R.id.content);
author = (EditText) findViewById(R.id.author);
loading = (ProgressBar) findViewById(R.id.loading);
send = (Button) findViewById(R.id.send);
clean = (Button) findViewById(R.id.clean);
send.setOnClickListener(this);
clean.setOnClickListener(this);

presenter = new PresenterImpl(this);
}

/**
* 显示和隐藏进度条
*/
@Override
public void showProgressBar() {
loading.setVisibility(View.VISIBLE);
}

@Override
public void hideProgressBar() {
loading.setVisibility(View.GONE);
}

/**
* 发送是成功还是失败各自需要做的事情
*/
@Override
public void sendSuccess() {
Toast.makeText(this,"发送成功！",Toast.LENGTH_SHORT).show();
}

@Override
public void sendFailed() {
Toast.makeText(this,"发送失败！",Toast.LENGTH_SHORT).show();
}

/**
* 清除发送内容
*/
@Override
public void cleanContent() {
content.setText("");
}

@Override
public void cleanAuthor() {
author.setText("");
}

/**
* 获取内容和作者
*/
@Override
public String getContent() {
return content.getText().toString().trim();
}
@Override
public String getAuthor() {
return author.getText().toString().trim();
}

/**
* Called when a view has been clicked.
* @param v The view that was clicked.
*/
@Override
public void onClick(View v) {
switch( v.getId()){
case R.id.send:
presenter.send();
break;
case R.id.clean:
presenter.clean();
break;
}
}

@Override
protected void onDestroy() {
presenter.destroy();
super.onDestroy();
}
}

 


ViewInterface

 

public class MainActivity extends AppCompatActivity implements ViewInterface, View.OnClickListener {


private EditText content;
private EditText author;
private Button send;
private Button clean;
private ProgressBar loading;

private PresenterImpl presenter;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
initView();
}
public void initView(){
content = (EditText) findViewById(R.id.content);
author = (EditText) findViewById(R.id.author);
loading = (ProgressBar) findViewById(R.id.loading);
send = (Button) findViewById(R.id.send);
clean = (Button) findViewById(R.id.clean);
send.setOnClickListener(this);
clean.setOnClickListener(this);

presenter = new PresenterImpl(this);
}

/**
* 显示和隐藏进度条
*/
@Override
public void showProgressBar() {
loading.setVisibility(View.VISIBLE);
}

@Override
public void hideProgressBar() {
loading.setVisibility(View.GONE);
}

/**
* 发送是成功还是失败各自需要做的事情
*/
@Override
public void sendSuccess() {
Toast.makeText(this,"发送成功！",Toast.LENGTH_SHORT).show();
}

@Override
public void sendFailed() {
Toast.makeText(this,"发送失败！",Toast.LENGTH_SHORT).show();
}

/**
* 清除发送内容
*/
@Override
public void cleanContent() {
content.setText("");
}

@Override
public void cleanAuthor() {
author.setText("");
}

/**
* 获取内容和作者
*/
@Override
public String getContent() {
return content.getText().toString().trim();
}
@Override
public String getAuthor() {
return author.getText().toString().trim();
}

/**
* Called when a view has been clicked.
* @param v The view that was clicked.
*/
@Override
public void onClick(View v) {
switch( v.getId()){
case R.id.send:
presenter.send();
break;
case R.id.clean:
presenter.clean();
break;
}
}

@Override
protected void onDestroy() {
presenter.destroy();
super.onDestroy();
}
}

 

  

 

业务逻辑层

 

*
* 控制 业务层，处理所有的业务逻辑，连接view 和 model
*/

public interface PresenterInterface {

public void send();
public void destroy();
public void clean();
}

 

 
从view层获取数据 ，做完相应的业务处理，把事情交给model校验数据，返回结果，根据结果控制view做出相应的UI处理

 

public class PresenterImpl implements PresenterInterface {


ViewInterface viewInterface;
ModelImpl model;
private Handler mHandler = new Handler();

public PresenterImpl() {
}

public PresenterImpl(ViewInterface viewInterface) {
this.viewInterface = viewInterface;
model = new ModelImpl();
}

@Override
public void send() {
//显示进度条
viewInterface.showProgressBar();
model.send(viewInterface.getContent(), viewInterface.getAuthor(), new ModelInterface.OnSendLinterer() {
@Override
public void sendSuccess() {
mHandler.post(new Runnable() {
@Override
public void run() {
viewInterface.sendSuccess();
viewInterface.hideProgressBar();
}
});
}

@Override
public void sendFailed() {
mHandler.post(new Runnable() {
@Override
public void run() {
viewInterface.sendFailed();
viewInterface.hideProgressBar();
}
});
}
});
}

@Override
public void destroy() {
viewInterface = null;
model.destory();
model = null;
}


@Override
public void clean() {
viewInterface.cleanAuthor();
viewInterface.cleanContent();
}
}

 

数据层

 

/*
* 数据层，做的事情就是为Presenter层提供数据
*/

public interface ModelInterface {


interface OnSendLinterer{
void sendSuccess();
void sendFailed();
}
public void send(String content, String author, OnSendLinterer onSendLinterer);
}

 

发送数据请求发送内容是否成功，这里用的是模拟 
public class ModelImpl implements ModelInterface {

private ExecutorService executorService ;

public ModelImpl(){
//获取一个线程池 根据 虚拟机可用的处理器的最大数量 +1 定义线程池大小
executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()+1);
}


@Override
public void send(String content, String author,final OnSendLinterer onSendLinterer) {
executorService.execute(new Runnable() {
/**
* When an object implementing interface <code>Runnable</code> is used
* to create a thread, starting the thread causes the object's
* <code>run</code> method to be called in that separately executing
* thread.
* <p>
* The general contract of the method <code>run</code> is that it may
* take any action whatsoever.
*
* @see Thread#run()
*/
@Override
public void run() {
//模拟网络请求的耗时操作
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//随机boolean 模拟发送成功或失败
Random random = new Random();
if( random.nextBoolean() ){
onSendLinterer.sendSuccess();
}else{
onSendLinterer.sendFailed();
}
}
});
//不再接受新的任务
// executorService.shutdown();
/*try {
future.get();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}*/
}
public void destory(){
executorService = null;
}
}

 

 

 
项目的结构

 

 

 

 

 

4、MVP模式什么时候用？
    可能有朋友会觉得MVP是为了模式而模式，开发中类变得多了，感觉还更加复杂了。我们知道，当需求过多过于复杂的时候，activity的代码量就会越来越多，可能一个activity中会有几千行代码，极大的影响了后期的维护和开发的成本。如果用上MVP就能极大限度的将activity中展示 业务处理 数据存取单独分离出来，虽然类文件增加了不少，但是整体来看程序和代码的结构还是很清晰的。所以，应用层开发的项目个人觉得使用MVP都是比较合适的。
使用MVP模式，建议按功能分包，利于后面的维护和开发

 

posted @ 2017-11-04 17:07  可爱的娃  阅读(1457)  评论(0)  编辑  收藏  举报