iOS MVVM设计模式

前言：

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。

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

（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

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