iOS中MVC,MVP,MVVM及VIPER设计模式介绍的文章有很多，开发过程MVC最常见的模式，MVVM也经常被在项目中实践，关于MVP，VIPER基本属于小众范畴，实际项目中开发的过程比较少.
MVC
MVC(Model-View-Controller)经典的设计模式，iOS项目本身的模板天然的MVC设计模式.MVC是官方推荐的主流架构，随着日常项目的开发，大家对以下MVC设计图应该不陌生.
Model--负责主要的数据或者操作数据,缓存数据.DataProvider和CacheData.
View--负责UI展示层,UIView,UITableView，UITableViewCell...
Controller--负责协调 Model 和 View，ViewController负责Model和View之间的通信，及View视图的事件响应.
Model,View与Controller三个模块间相互都有通信，紧密耦合，降低三者之间的复用性.如果进行项目开发能够控制的好，也能支撑项目不断前进，实际开发中MVC的更像下面的设计图:
iOS中UIViewController相当于View和Controller耦合，就容易造成控制器臃肿(Massive View Controller).MVC开发过程能将模块典型的分开，这是MVC的最大优势，但是MVC模式下的测试性特别差，MVC模式下页面UI测试如果进行单独测试非常困难，一般都是能简单的进行接口层面的测试.可以尝试将UIViewController的过于臃肿的UI逻辑和业务逻辑抽取出来，虽然MVC只有三层，并不是说开发过程中只有这三层.
MVP
先来看一张MVP之间模块通信图:
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的绑定库 RZDataBinding 和 SwiftBond
完全的函数响应式编程,ReactiveCocoa、RxSwift或者 PromiseKit
前端的Angular 和 Ember 基于MVVM模式的开发.
<blockquote>MVVM 在实际使用中，确实能够使得 Model 层和 View 层解耦，但是如果你需要实现 MVVM 中的双向绑定的话，那么通常就需要引入更多复杂的框架来实现了。
对此，MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点：
第一点：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
第二点：对于过大的项目，数据绑定需要花费更多的内存。
某种意义上来说，我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是，这个缺点同时也被很多人认为是优点。</blockquote>
VIPER
VIPER是划分责任的粒度是很好的选择，VIPER在责任划分层面进行了迭代，VIPER分为五个层次:
交互器(Interactor) -- 包括关于数据和网络请求的业务逻辑，例如创建一个实体（数据），或者从服务器中获取一些数据。为了实现这些功能，需要使用服务、管理器，但是他们并不被认为是VIPER架构内的模块，而是外部依赖.
展示器(Presenter) -- 包含UI层面的业务逻辑以及在交互器层面的方法调用.
实体(Entities) -- 普通的数据对象，不属于数据访问层次，因为数据访问属于交互器的职责.
路由器(Router) -- 用来连接VIPER的各个模块.
VIPER像乐高积木来搭建城堡，流程模式固定，如果项目比较大，那么VIPER是一把利刀.如果项目比较小，那么VIPER就优点大材小用，而且会影响开发的速度.
哲学家说过存在即合理，每种架构模式都有自己的适用场景，如果在项目中MVC能保持团队快速开发也不一定非要切换到MVVM，架构模式跟项目掌控者，公司的业务方向有很大关系.没有绝对的正确，也没有绝对的错误.
