本文介绍: 这篇文章简单介绍MVC、MVP和MVVM三种架构,并配上一个简单的Swift demo来区分MVC和MVVM两种架构

MVC、MVP、MVVM

前言

篇文章简单介绍MVC、MVP和MVVM三种架构,并配上一个简单的Swift demo来区分MVC和MVVM两种架构

MVC

传统MVC

下图传统结构MVC,可以看到这种结构是紧耦合的,不推荐使用

传统的MVC

苹果的MVC

下图,这是苹果MVC架构的愿景,Controller作为View和Model中介,这样它们就解耦了。

Cocoa MVC

各层的职责如下所示

如上图所示,M和View应该是完全隔离的,由C作为中间人来负责二者交互,同时三者是完全独立分开的,这样可以保证M和V的可测试性和复用性。

MVC在iOS中的实现

由于Apple的规范一个界面呈现需要构建一个viewcontroller,而每个viewcontroller都带有一个view,这就导致C和V紧密耦合在一起构成了iOS里面的C层,这明显违背了MVC的初衷。实际结构下图

img

根据苹果对MVC架构规范的描述原文戳这里viewcontroller其实viewcontroller组合,目的就是为了提高开发效率简化操作。但这样也会导致一个问题,就是View层的代码全堆到了VC,比如VC中构建View,View的显示逻辑处理等等。

MVC各层功能

controller层(VC)
model
view

关于Model层,这里有一段文章引用说明了真正的Model层实际不应该只有几个结构属性应该有的是数据的业务逻辑

理解Model层:

首先要正确理解MVC中的M是什么?他是数据模型吗?答案是NO。他的正确定义业务模型。也就是你所有业务数据和业务实现逻辑应该定义在M层里面,而且业务逻辑的实现和定义应该和具体的界面无关,也就是和视图以及控制之间没有任何的关系,它是可以独立存在的,您甚至可以将业务模型单独编译一个静态库来提供给第三方或者其他系统使用

在上面经典MVC图中也很清晰的描述了这一点: 控制负责调用模型,而模型则将处理结果发送通知控制控制通知视图刷新。因此我们不能将M简单的理解一个个干巴巴的只有属性没有方法的数据模型

其实里面涉及到一个基本设计原则,那就是面向对象基本设计原则:就是什么是类?类应该是一个个具有不同操作不同属性对象抽象(类是属性方法集合)。 我想现在任何一个系统里面没有出现过一堆只有数据而没有方法的数据模型集合被定义为一个单独而抽象模型层来供大家使用吧。 我们不能把一个保存数据模型的文件夹来当做一个层,这并不符合横向切分的规则

Model层实现正确姿势:

  1. 定义的M层中的代码应该和V层和C层完全无关的,也就是M层的对象是不需要依赖任何C层和V层的对象独立存在的。整个框架设计最优结构是V层不依赖C层而独立存在,M层不依赖C层和V层独立存在,C层负责关联二者,V层只负责展示,M层持有数据和业务的具体实现,而C层则处理事件响应以及业务调用以及通知界面更新。三者之间一定要明确的定义为单向依赖,而不应该出现双向依赖
  2. M层要完成对业务逻辑实现封装,一般业务逻辑最多的是涉及到客户端服务器之间的业务交互。M层里面要完成对使用网络协议(HTTP, TCP,其他)、和服务器之间交互的数据格式(XML, JSON,其他)、本地缓存数据库存储(COREDATA, SQLITE,其他)等所有业务细节封装,而且这些东西都不能暴露给C层。所有供C层调用的都是M层里面一个个业务类所提供的成员方法实现。也就是说C层是不需要知道也不应该知道客户端服务器通信使用的任何协议,以及数据报文格式,以及存储方面的内容。这样的好处是客户端服务器之间的通信协议数据格式,以及本地存储的变更都不会影响任何的应用整体框架,因为提供给C层的接口不变,只需要升级更新M层的代码就可以了。比如说我们想将网络请求库从ASI换成AFN就只要在M层变化就可以了,整个C层和V层的代码不变。

MVP

结构如下图。

Passive View 变体 — MVP

MVC中没有对业务逻辑和业务展示进行区分,MVP就是针对这一点进行的优化,它将业务逻辑和业务展示做了一层隔离。M和V功能不变, 原来的C现在只负责布局, 而所有的业务逻辑全都转移到了P层。P层处理完了业务逻辑,如果要更改view显示,那么可以通过回调来实现,这样可以减轻耦合,MVP从视图层中分离行为(事件响应)和状态属性用于数据展示),它创建了一个视图抽象,也就是presenter层,而视图就是P层的『渲染结果。P层中包含所有的视图渲染需要的动态信息,包括视图内容textcolor)、组件是否启用enable),除此之外还会将一些方法暴露视图用于某些事件的响应。

MVP通信过程

img

  1. 当视图接收到来自用户的事件时,会将事件转交给 Presenter 进行处理;
  2. 被动的视图实现presenter代理,当需要更新视图时 Presenter回调代理来更新视图的内容,这样让presenter专注于业务逻辑,view专注于显示逻辑
  3. Presenter 负责对模型进行操作和更新,在需要时取出其中存储信息
  4. 当模型层改变时,可以将改变的信息发送给观察者 Presenter

MVVM

MVVM由三个部分组成,也就是 Model、View 和 ViewModel;其中视图模型(ViewModel)其实就是 MVP 模式中的P,在 MVVM 中叫做VM,架构图如下

img

MVVM相对于MVP做的改进就是对VM/P和view做了双向的数据和命令绑定利用Binder机制使得Model和View可以状态同步

具体实例看MVC与MVP/MVVM的实现对比

acc4309009746c0a5870c637ecee5955

可以看到项目中,MVVM比MVC多了一个ViewModel层,这是两者的不同我们先来看看相同的Model和ViewController,两者除了命名不同其他的都相同,所以以下只展示一种。

Model

39fd8c1f81071de0e1bf7eb531986e5e

ViewController

3d622c59990f8b57adcd77f9b1072cbc

fetchData部分写的内容模拟网络请求数据,代码如下图。

fetchData

fb553ca7ab781e35740ca3e5fcd96ead

接下来我们看到MVC中的View层

MVCView

0bf5b3ed1c2e294058b09ae28e4a91ac

可以看到在这里对业务的显示和业务的逻辑处理都放在了View层。

我们反观MVVM架构中,加入了一个ViewModel,它对业务逻辑部分抽象出了一个类,代码如下

cdc371f737ec6549762c0c7bbb3a2166

最后我们在View中,只用处理业务展示部分即可,代码如下

ee004282b845b4a90138f557e8de24dc
以上就是MVC、MVP、MVVM的简要介绍

原文地址:https://blog.csdn.net/yueliangmua/article/details/134746815

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_30644.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注