浅谈MVC、MVP、MVVM的区别

时间:2022-06-23 21:16:31

前言


MVC的概念很早就知道,现在发现还有MVP、MVVM,那么这些设计模式有什么区别呢?简单谈一下自己的理解

内容

前言

   MVC、MVP和MVVM都是为了解决界面呈现和逻辑代码分离而出现的模式。经典的MVC模式是M-V-X模式的老祖宗,MVP和MVVM都是在MVC的基础上演化而来,和MVC框架模式一样,Model模型处理数据代码。这些架构的目的都是为了提高代码的复用率、降低代码的耦合度、便于模块测试、版本的迭代更新,下面对每个架构进行简单的介绍与使用。

Mvc架构

概述

   MVC全名是Model View Controller,如下图,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑,是Java企业级应用的典型架构,当然Android中界面部分也采用了当前比较流行的MVC框架,笔者在最开始接触android的时候用的比较多的是Mvc架构。

浅谈MVC、MVP、MVVM的区别

   如上图所示,其中M层处理数据,业务逻辑等;V层处理界面的显示结果;C层起到桥梁的作用,来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。

Android中的Mvc

   在Android中:

  1. 视图层:一般采用XML文件进行界面的描述,这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改,大大增强了代码的可维护性。
  2. 控制层:Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码,要通过Activity交割Model业务逻辑层处理,这样做的另外一个原因是Android中的Actiivity的响应时间是5s,如果耗时的操作放在这里,程序就很容易被回收掉。
  3. 模型层(Model):我们针对业务模型,建立的数据结构和相关的类,就可以理解为AndroidApp的Model,Model是与View无关,而与业务相关的。对数据库的操作、对网络等的操作都应该在Model里面处理,当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。

例子

   请访问下面地址下载代码Mvc,例子很简单,就是一个验证登入的例子,但是能很好的代入Mvc的特点。

Android中的Mvc的缺点

   MVC虽然将界面呈现和逻辑代码分离了,但是在实际的Android开发中并没有完全起到想要的作用。View对应的XML文件实际能做的事情很少,很多界面显示由Controllor对应的Activity给做了,这样使得Activity变成了一个类似View和Controllor之间的一个东西。如果是小型项目,MVC是没任何问题的。因为项目比较小嘛,开发周期比较短,Controllor臃肿点也可以理解。假设项目越来越来,尤其是再加上比较复杂的逻辑,这时候一个Activity几千行代码就比较蛋疼了,再加点迷之缩进,那酸爽~~啧啧。所以MVC比较适用于快速开发的小型项目。

   因为在在Android开发中,Activity并不是一个标准的MVC模式中的Controller,它的首要职责是加载应用的布局和初始化用户 界面,并接受并处理来自用户的操作请求,进而作出响应。随着界面及其逻辑的复杂度不断提升,Activity类的职责不断增加,以致变得庞大臃肿。

Mvp架构

概述

   MVP从更早的MVC框架演变过来,与MVC有一定的相似性:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。

浅谈MVC、MVP、MVVM的区别

   MVP框架由3部分组成:View负责显示,Presenter负责逻辑处理,Model提供数据。在MVP模式里通常包含3个要素(加上View interface是4个):

  • View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)

  • Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)

  • Presenter:作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。

  • View interface:需要View实现的接口,View通过View interface与Presenter进行交互,降低耦合,方便进行单元测试

与Mvc的区别

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

例子

   请访问下面地址下载代码Mvp ,例子是在Mvc的基础先进行改进的,从Mvp的例子里可以看出:

  • 在MVP中,Activity的代码不臃肿;
  • 在MVP中,Model(IUserModel的实现类)的改动不会影响Activity(View),两者也互不干涉,而在MVC中会;
  • 在MVP中,IUserView这个接口可以实现方便地对Presenter的测试;
  • 在MVP中,UserPresenter可以用于多个视图,但是在MVC中的Activity就不行。

Mvp的缺点

   MVP模式虽然很好,但是增加了很多的接口和实现类。代码逻辑虽然清晰,但是代码量要庞大一些。当刚接手一个烂尾的MVP模式,如果事先没了解过MVP,会不会一脸的懵逼。所以MVP比较适用于中小型的项目,大型项目慎用。

Mvvm架构

概述

   MVVM可以算是MVP的升级版,其中的VM是ViewModel的缩写,ViewModel可以理解成是View的数据模型和Presenter的合体,ViewModel和View之间的交互通过Data Binding完成,而Data Binding可以实现双向的交互,这就使得视图和控制层之间的耦合程度进一步降低,关注点分离更为彻底,同时减轻了Activity的压力。

浅谈MVC、MVP、MVVM的区别

架构的演进

   MVC -> MVP -> MVVM 这几个软件设计模式是一步步演化发展的,MVVM 是从 MVP 的进一步发展与规范,MVP 隔离了MVC中的 M 与 V 的直接联系后,靠 Presenter 来中转,所以使用 MVP 时 P 是直接调用 View 的接口来实现对视图的操作的,这个 View 接口的东西一般来说是 showData、showLoading等等。M 与 V已经隔离了,方便测试了,但代码还不够优雅简洁,所以 MVVM 就弥补了这些缺陷。在 MVVM 中就出现的 Data Binding 这个概念,意思就是 View 接口的 showData 这些实现方法可以不写了,通过 Binding 来实现。

例子

   请访问下面地址下载代码Mvvm ,对于Mvvm读者用的不多,所以只能是班门弄斧了,想要多了解的话,去问问度娘或谷歌吧。