iOS-MVC,MVP,MVVM及VIPER简介

作者: FlyElephant | 来源:发表于2017-05-01 11:09 被阅读525次

    iOS中MVC,MVP,MVVM及VIPER设计模式介绍的文章有很多,开发过程MVC最常见的模式,MVVM也经常被在项目中实践,关于MVP,VIPER基本属于小众范畴,实际项目中开发的过程比较少.

    MVC

    MVC(Model-View-Controller)经典的设计模式,iOS项目本身的模板天然的MVC设计模式.MVC是官方推荐的主流架构,随着日常项目的开发,大家对以下MVC设计图应该不陌生.


    MVC.png

    Model--负责主要的数据或者操作数据,缓存数据.DataProvider和CacheData.
    View--负责UI展示层,UIView,UITableView,UITableViewCell...
    Controller--负责协调 Model 和 View,ViewController负责Model和View之间的通信,及View视图的事件响应.

    Model,View与Controller三个模块间相互都有通信,紧密耦合,降低三者之间的复用性.如果进行项目开发能够控制的好,也能支撑项目不断前进,实际开发中MVC的更像下面的设计图:


    MVC.png

    iOS中UIViewController相当于View和Controller耦合,就容易造成控制器臃肿(Massive View Controller).MVC开发过程能将模块典型的分开,这是MVC的最大优势,但是MVC模式下的测试性特别差,MVC模式下页面UI测试如果进行单独测试非常困难,一般都是能简单的进行接口层面的测试.可以尝试将UIViewController的过于臃肿的UI逻辑和业务逻辑抽取出来,虽然MVC只有三层,并不是说开发过程中只有这三层.

    MVP

    先来看一张MVP之间模块通信图:


    MVP.png

    MVP看起来和MVC特别像双胞胎兄弟,最大的不同大于View和Model之间切断了通信关系,严格的按照View->Presenter->Model的顺序执行,MVP中的协调器Presenter并没有对ViewController的生命周期做任何改变,如果要进行测试,我们只需要模拟Presenter中的数据给View即可.Presenter中没有UI布局相关的代码,只负责更新View的数据和状态,以及Model之间的通信.

    iOS项目大多数是都是基于MVC开发的,如果切换到MVP应该是时间成本最小的,但是如果业务逻辑比较多,最终会造成Presenter的臃肿,本质上没有解决太多问题.因此MVP项目相对于其他框架普及度不高.

    MVVM

    MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致,唯一的区别是,它采用双向绑定(data-binding),View的变动,自动反映在 ViewModel,ViewModel的变动也会反应在View上.

    MVVM 在实际使用中,确实能够使得 Model 层和 View 层解耦,但是如果你需要实现 MVVM 中的双向绑定的话可以通过开源库实现:

    基于KVO的绑定库 RZDataBindingSwiftBond

    完全的函数响应式编程,ReactiveCocoaRxSwift或者 PromiseKit

    FlyElephant.png

    前端的AngularEmber 基于MVVM模式的开发.

    <blockquote>MVVM 在实际使用中,确实能够使得 Model 层和 View 层解耦,但是如果你需要实现 MVVM 中的双向绑定的话,那么通常就需要引入更多复杂的框架来实现了。
    对此,MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点:
    第一点:数据绑定使得 Bug 很难被调试。你看到界面异常了,有可能是你 View 的代码有 Bug,也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置,要定位原始出问题的地方就变得不那么容易了。
    第二点:对于过大的项目,数据绑定需要花费更多的内存。
    某种意义上来说,我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是,这个缺点同时也被很多人认为是优点。</blockquote>

    VIPER

    VIPER是划分责任的粒度是很好的选择,VIPER在责任划分层面进行了迭代,VIPER分为五个层次:

    VIPER.png
    • 交互器(Interactor) -- 包括关于数据和网络请求的业务逻辑,例如创建一个实体(数据),或者从服务器中获取一些数据。为了实现这些功能,需要使用服务、管理器,但是他们并不被认为是VIPER架构内的模块,而是外部依赖.

    • 展示器(Presenter) -- 包含UI层面的业务逻辑以及在交互器层面的方法调用.

    • 实体(Entities) -- 普通的数据对象,不属于数据访问层次,因为数据访问属于交互器的职责.

    • 路由器(Router) -- 用来连接VIPER的各个模块.

    VIPER像乐高积木来搭建城堡,流程模式固定,如果项目比较大,那么VIPER是一把利刀.如果项目比较小,那么VIPER就优点大材小用,而且会影响开发的速度.

    哲学家说过存在即合理,每种架构模式都有自己的适用场景,如果在项目中MVC能保持团队快速开发也不一定非要切换到MVVM,架构模式跟项目掌控者,公司的业务方向有很大关系.没有绝对的正确,也没有绝对的错误.

    参考链接:
    iOS Architecture Patterns
    被误解的 MVC 和被神化的 MVVM

    相关文章

      网友评论

      本文标题:iOS-MVC,MVP,MVVM及VIPER简介

      本文链接:https://www.haomeiwen.com/subject/hmwxtxtx.html