iOS MVVM设计模式

时间 2019-11-29

标签 ios mvvm 设计模式栏目 iOS 繁體版

原文原文链接

前言：html

MVC 模式是iOS业内人士耳熟能详的，后来逐渐有人提出了MVVM的设计模式，这篇文章的目的是在熟知MVC模式的基础上进一步认知什么是MVVM模式，而且在工做中MVVM思想怎么能对咱们有助力做用。

一 .MVC:(Model View Controller) 是构建iOS App的标准模式。大多数开发者也必定在平常的开发中把MVC思想运用的淋漓尽致。

1.基本目的 ios

将视图和数据分离开来，下降藕荷度编程

2.基本几个要点

(1)Model : （数据模型，数据）持有并负责管理数据：封装，存储，处理数据运算等设计模式

(2)View : (视图，显示) 显示UI呈现给用户，对用户的target action 行为有响应缓存

(3)Controller ：（控制器，管理中心）调度程序工做，调解Model和View之间的交互，所有的表示逻辑、业务逻辑都在此 eg网络请求、事件响应方法网络

3.工做原理： （参考1）

1）Model 和 View 永远不能相互通讯，只能经过 Controller 传递。架构

2）Controller 能够直接与 Model 对话（读写调用 Model），Model 经过 Notification 和 KVO 机制与 Controller 间接通讯。函数

3）Controller 能够直接与 View 对话，经过 outlet，直接操做 View，outlet 直接对应到 View 中的控件，View 经过 action 向 Controller 报告事件的发生(如用户 Touch 我了)。Controller 是 View 的直接数据源（数据极可能是 Controller 从 Model 中取得并通过加工了）。Controller 是 View 的代理（delegate)，以同步 View 与 Controller。单元测试

4.优势学习

（1）实现了基本目的：将视图和数据分离开来，下降藕荷度

(2) 方便debug调试问题出处是Controller仍是View仍是Model

5. 缺点

（1）随着项目的不断迭代开发，Controller 承担业务量加大，负担变重。所以网上说起MVVM好处时候难免都diss一下MVC是“Massive View Controller（重量级视图控制器）”

（2）较差的可测试性

（3）遗失的网络逻辑 //太重的Controller 被堆砌，很难从堆砌的网络逻辑中查找对应哪个具体UI展现的

6.目前，咱们作的尽量给Controller 减负的方式

（1）遵循基本OC编码规则，明确函数分组和协议实现中使用#pragma mark -来分类方法。好处来讲，代码结构清晰。不论厚重与否，咱们都遵循统一编码规则，从review,迭代的角度，都是相对有利的

(2) 使用类别category，来管理控制器中的业务，一个业务一个同级别类别category。例如首页元素：

yiji和起居板块
健康档案计划
调理方案
症状
文章list

这些丰富的数据源来一个或者多个接口，UI展现出来有其特有的位置，因而选择使用类别category的方式来处理。

注意：使用类别只能离散化代码，逻辑层面更优秀一些，但不能真正减轻ViewController的负担。绝对依赖，仍是有问题。进一步优化仍是值得深挖挖

（3）分离数据源：实现 UITableViewDataSource 代理协议相关的代码封装成一个类。这个我以前写过一个博客 参考连接2。

注意：这种方法最好是团队合做在开发上有交集，要绝对你们都知晓你这么作，并能认同这种优化方式，不然一个后果是，别人读不懂你的代码，同事又写了一遍。。。反而这种分离数据源的方法是一种过渡设计了

（4）使用一些优秀第三方减小代码量

eg. Masonry:在纯代码手动代码设置视图的约束时，优秀得无可挑剔

YYKit系列:真是业内大牛利用本身学习心得开源出来的，很是牛逼，阅读一遍源码，本身再进行开发时候都下笔若有神的感受。

其中YYModel真是比本身写的那个反射好多了，足够面向对象，足够优秀,忽然在大神面前感受本身就是渣渣。继续努力，保持对学习进步的热忱之心

（5）尊重面相对象，该封装的方法，模块都进行封装。

eg.好比AFNetWorking ,作好封装。把相近业务网络请求部分放进一个类别里面，在控制器中直接调用咱们本身的封装便可

二.MVVM： （Model View View-Mode）是MVC的变种衍生出的一种模式“ 一种能够很好地解决Massive View Controller问题的办法就是将 Controller 中的展现逻辑抽取出来，放置到一个专门的地方，而这个地方就是 viewModel ”

1.基本目的 :解决重MVC问题，将Controller中的展现逻辑抽取出来（其实目的都是分离Model与View 更好的解耦合）

2.基本几个要点

(1)Model : 数据层和MVC中model同样

(2)ViewController/View: 展现层它包括了一些数据绑定，事件，和行为和 UI展现给用户（ViewController只作了部分胶水做用，View仍是纯展现，触发事件响应给）

(3)ViewModel ：数据模型封装业务逻辑，业务网络处理，封装数据缓存，即把MVC中控制器中的以上三部分等放到ViewModel里面

3.工做原理图：(参考连接4)

核心ViewModel设计

（1）与View成对设计，负责关联Model和处理UI逻辑，是界面的非展示部分。

把原MVC中控制器里展现逻辑提取出来。参考图中，主要是封装业务逻辑，业务网络处理，封装数据缓存。

4.优势

（1）相对MVC 进一步实现了 UI与逻辑的分离解耦合

（2）可测试性：单元测试方便，基本集中于测试ViewModel

（3）配合ReactiveCocoa疗效好。里面丰富运用了Hook思想响应式编程思想。。。监听数据变化更新UI

5.缺点

（1）简单场景不适合MVVM模式，过犹不及反而显得太重。

每次进行架构或者功能设计时候都应该要仔细思考，选择的设计模式是否合理有效，是否可以可持续发展

（2）ViewModel自己也会愈来愈沉重，项目业务逻辑，交互逻辑增长。

ViewModel可复用性不太可观，高度复用耦合性会加大。因此会不断建立各中ViewModel，容易出现类型爆炸，提升维护成本。

(3) 对于过大的项目，数据绑定和数据转化须要花费更多的内存。

（4）数据绑定机制致使问题转移难以调试bug，eg由于表象是UI赋值显示问题，可是还多是模型转化，根本问题被转移了。。。

以上

参考

1.https://www.cnblogs.com/QianChia/p/5771082.html

2. http://www.cnblogs.com/someonelikeyou/p/6522150.html

3. http://www.cocoachina.com/ios/20150122/10987.html 架构模式

4. http://www.cocoachina.com/ios/20170612/19500.html

5. https://www.jianshu.com/p/a21dec9ab84f