iOS - MVVM 架构模式

1、MVVM

  • 从字面意思来理解,MVVM 即 Modal View ViewModel(模型 视图 视图模型)。MVC 是一个用来组织代码的权威范式,也是构建 iOS App 的标准模式。Apple 甚至是这么说的。在 MVC 下,所有的对象被归类为一个 model,一个 view,或一个 controller。Model 持有数据,View 显示与用户交互的界面,而 View Controller 调解 Model 和 View 之间的交互。然而,随着模块的迭代我们越来越发现 MVC 自身存在着很多不足。因此,MVVM 从其他应用而出,在 iOS 中从此我们完全将业务逻辑加以区分并使用这套思想。在 MVVM 中他的设计思路和 MVC 很像。它正式规范了视图和控制器紧耦合的性质,并引入新的组件 ViewModel。此外,它还有像监管版本的 MVP 那样的绑定功能,但这个绑定不是在 View 和 Model 之间而是在 View 和 ViewModel 之间。
  • 1)MVVM 模式下的三个特性的分析
    • 任务均摊 -- MVVM 的 View 要比 MVP 中的 View 承担的责任多。因为前者通过 ViewModel 的设置绑定来更新状态,而后者只监听 Presenter 的事件但并不会对自己有什么更新。
    • 可测试性 -- ViewModel 不知道关于 View 的任何事情,这允许我们可以轻易的测试 ViewModel。同时 View 也可以被测试,但是由于属于 UIKit 的范畴,对他们的测试通常会被忽略。
    • 易用性 -- 在实际开发中必须把 View 中的事件指向 Presenter 并且手动的来更新 View,如果使用绑定的话,MVVM 代码量将会小的多。
  • 2)iOS MVVM 示意图:

    • 在 MVVM 里,view 和 view controller 正式联系在一起,我们把它们视为一个组件。视图 view 仍然不能直接引用模型 Model,当然 controller 也不能。相反,他们引用视图模型 View Model。
    • View Model 是一个放置用户输入验证逻辑,视图显示逻辑,发起网络请求和其他各种各样的代码的极好的地方。有一件事情不应归入 View Model,那就是任何视图本身的引用。View Model 的概念同时适用于于 iOS 和 OS X(换句话说,不要在 View Model 中使用 #import UIKit.h)。
    • 由于展示逻辑(presentation logic)放在了 View Model 中(比如 Model 的值映射到一个格式化的字符串),视图控制器本身就会不再臃肿。当然你开始使用 MVVM 的最好方式时可以先将一小部分逻辑放入视图模型,然后当你逐渐习惯于使用这个范式的时候再迁移更多的逻辑到视图模型中。
    • 使用 MVVM 会轻微的增加代码量,但总体上减少了代码的复杂性。
时间: 2024-10-25 13:05:03

iOS - MVVM 架构模式的相关文章

iOS - MVP 架构模式

1.MVP 从字面意思来理解,MVP 即 Modal View Presenter(模型 视图 协调器),MVP 实现了 Cocoa 的 MVC 的愿景.MVP 的协调器 Presenter 并没有对 ViewController 的生命周期做任何改变,因此 View 可以很容易的被模拟出来.在 Presenter 中根本没有和布局有关的代码,但是它却负责更新 View 的数据和状态.MVC 和 MVP 的区别就是,在 MVP 中 M 和 V 没有直接通信. MVP 是第一个如何协调整合三个实际

iOS - MVC 架构模式

1.MVC 从字面意思来理解,MVC 即 Modal View Controller(模型 视图 控制器),是 Xerox PARC 在 20 世纪 80 年代为编程语言 Smalltalk-80 发明的一种软件设计模式,至今已广泛应用于用户交互应用程序中.其用意在于将数据与视图分离开来.在 iOS 开发中 MVC 的机制被使用的淋漓尽致,充分理解 iOS 的 MVC 模式,有助于我们程序的组织合理性. MVC 的几个明显的特征和体现: View 上面显示什么东西,取决于 Model. 只要 M

iOS - VIPER 架构模式

1.VIPER 从字面意思来理解,VIPER 即 View Interactor Presenter Entity Router(展示器(视图) 交互器 协调器 实体(数据) 路由器),迄今为止,划分责任的粒度是很好的选择.VIPER 在责任划分层面进行 了迭代,VIPER 分为五个层次: 展示器 -- 包含 UI 层面的业务逻辑以及在交互器层面的方法调用. 交互器 -- 包括关于数据和网络请求的业务逻辑,例如创建一个实体(数据),或者从服务器中获取一些数据.为了实现这些功能,需要使用服务.管理

精华阅读第 9 期 |滴滴出行 iOS 客户端架构演进之路

「架构都是演变出来的,没有最好的架构,只有最合适的架构!」最近,滴滴出行平台产品中心 iOS 技术负责人李贤辉接受了 infoQ 的采访,阐述了滴滴的 iOS 客户端架构模式与演变过程.李贤辉也是移动开发精英俱乐部中的一员,所以本期重点推荐了这篇文章. 更多精彩,请看这里,内容系国内 ITOM 管理平台 OneAPM 整理: 滴滴出行 iOS 客户端架构演进之路 成长为 iOS 大 V 的秘密 React Native开源项目-iOS新浪微博客户端 可靠 UDP 传输 精华阅读第8期|Alpha

iOS 开发中的 Flux 架构模式

本文讲的是iOS 开发中的 Flux 架构模式, 在半年前,我开始在 PlanGrid iOS 应用程序中采用 Flux 架构(开发).这篇文章将会讨论我们从传统的 MVC 转换到Flux的动机,同时分享我们目前积累到的经验. 我尝试通过讨论代码来描述我们大部分的 Flux 实现, 它用于我们今天的产品中. 如果你只对综合结果感兴趣, 请跳过这篇文章的中间部分. 为什么从 MVC 转移 为了引入我们的决定, 我想要先谈一谈 PlanGrid 这个应用遇到的一些挑战.一些问题仅针对企业级应用程序,

Square对iOS App架构的新尝试---Ziggurat

今年六月,我做了一场关于避免臃肿的ViewController的演讲,用Swift讲解了一种采用"单向数据流"的架构模式.当时并没有发布相关的博客,甚至没有给这个架构起个名字.现在两者都有了.首先介绍一下Ziggurat:它是一种通过不可变的视图模型和单向数据流来实现的分层的.易测试的架构模式. 这个架构的名字Ziggurat是根据阶梯状的金字塔得来的.像金字塔的阶梯一样,数据以数据流的形式单向地沿着App的层级传递,并逐层缩小.单向不可变的数据流可以减少认知负载,同时使类也变得更加瘦

android. mvc,mvp,mvvm架构分析

问题描述 android. mvc,mvp,mvvm架构分析 android现在流行三种架构,mvc,mvp,mvvm网上介绍的文档很多都介绍的比较浅,最重要的是没有完整的比较大的项目结合分析, 解决方案 本质上来说,mvc mvp mvvm是差不多的东西,只是在model,viewmodel和businessmodel的职责划分上略有不同.而且在"完整的比较大的项目",其实根本不能教条使用教科书上的某一种模式."介绍的文档很多都介绍的比较浅"恰恰说明了这一点--把

IOS应用架构思考二(网络图片库)

移动端架构中图片库是非常重要的一环,其实图片库也可以理解为网络库的一种特殊使用模式,为了满足需要,图片库至少要满足以下特点: 提供一个加载入口,通常以UIImageView的类别方法setImageWithURL:...开始 支持异步网络加载图片 支持内存缓存和文件缓存 确保同一张图片不会被重复下载 主流图片格式的解码 著名的优秀关于图片加载的库有: SDWebImage AFNetworking EGOImageLoading 已经年久失修 1. Load入口 关于Load入口方式,一般有两种

理解javascript中的MVVM开发模式

          MVVM的全称是Model View ViewModel,这种架构模式最初是由微软的MartinFowler作为微软软件的展现层设计模式的规范提出,它是MVC模式的衍生物,MVVM模式的关注点在能够支持事件驱动的UI开发平台,例如HTML5,[2][3] WindowsPresentation Foundation (WPF), Silverlight 和 t ZK framework,Adobe Flex.           对这种模式的实现,大部分都是通过在view层声