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

评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值