iOS MVVM设计模式

布满荆棘的人生 2021-12-16 17:59 281阅读 0赞

**前言：**

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

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

**1.基本目的  **

将视图和数据分离开来，降低藕荷度

**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。][2]**

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

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

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

**YYKit系列:**真是业内大牛利用自己学习心得开源出来的，非常牛逼，阅读一遍源码，自己再进行开发时候都下笔如有神的感觉。

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

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

eg.比如AFNetWorking ,做好封装。把相近业务网络请求部分放进一个类别里面，在控制器中直接调用我们自己的封装即可

![494253-20180323222814856-1830027087.png][]

**二.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)**

**    ![494253-20180323234849586-930510264.jpg][]**

**   **

**     **

**     核心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**

转载于:https://www.cnblogs.com/someonelikeyou/p/8635241.html

[2]: http://www.cnblogs.com/someonelikeyou/p/6522150.html
[494253-20180323222814856-1830027087.png]: /images/20211216/470ce7eb4095479e863667a1c3cabe89.png
[494253-20180323234849586-930510264.jpg]: /images/20211216/740492db77e64a0a88f55897c3031ed6.png