iOS VIPER架构实践(一)：从MVC到MVVM到VIPER

本文链接：https://blog.csdn.net/zhanggenpin/article/details/79095618

本文介绍了iOS架构从MVC、MVP到MVVM的演变，并详细探讨了VIPER架构，强调了VIPER的职责明确、可测试性和低耦合度等优点，以及其在模块初始化和代码量增加方面的挑战。作者分享了VIPER架构的实践经验和对未来发展的看法，鼓励开发者拥抱VIPER。

摘要由CSDN通过智能技术生成

简介

最近半年在写app的时候，研究了一下各种iOS代码架构，最后选择了VIPER进行实践，在此对实践中遇到的各种设计问题做一番总结，并分享造出的轮子。VIPER演示demo：ZIKViper，模块路由工具地址：ZIKRouter。

对代码风格和架构有兴趣的同学，肯定都已经在很多地方见过各种架构的介绍。MVC、MVP、MVVM、VIPER，细分程度逐渐上升。这些架构设计大部分都是来自MVC，只是各自用不同的方式对MVC进行了细分，在此只对MVC、MVP和MVVM作精简介绍，想要详细了解可以参考这些文章：

iOS 架构模式–解密 MVC，MVP，MVVM以及VIPER架构,

浅谈 MVC、MVP 和 MVVM 架构模式。

MVC

Model-View-Controller。MVC简单地将一个模块分为3部分：

View是展示给外部的界面
Model是Controller内部管理的数据模型，和各种数据操作工具
Controller负责将Model的变化更新到View
Controller负责处理来自View的事件

MVC的划分粒度很粗，因此有很多种具体实现，各个实现有差异，因此并没有一个十分明确的标准定义。

苹果的MVC

苹果的Cocoa Touch就遵照了MVC的设计，一个界面分为UIView和UIViewController，UIView负责渲染和接收触摸事件，UIViewController负责子view之间的布局、组合、更新以及事件处理。

尽管苹果已经给我们提供了简单的MVC支持，但是在实践中我们却常常没有遵守MVC。原因在于Cocoa Touch中的Model部分是由我们自己负责管理的，并没有提供原生的设计支持。所以有时候会出现这样的情况：一个UIView为了方便，提供了一个从某个model进行配置的方法。乍一看十分合理，但是仔细想想就会发现，这么做已经将View和Model耦合，不符合苹果官方的MVC规范(The Role of View Controllers)。

另外，UIViewController存在的一些问题，导致了它很容易变得臃肿和耦合。

首先，UI