再窥iOS架构模式

咱们为何要在架构上费心思？

答案是：为了减小在每作一个功能的时候所耗费的人力资源。

移动开发人员会在如下三个层面上评估一个架构的好坏：

1. 各个功能分区的职责分配是否均衡
2. 是否具备易测试性
3. 是否易于使用和维护

	职责分配的均衡性	易测试性	易用性
紧耦合MVC	❌	❌	✅
Cocoa MVC	❌ V和C是耦合的	❌	✅⭐
MVP	✅ 独立的视图生命周期	✅	通常：代码较多
MVVM	✅	通常：视图（View）存在对UIKit的依赖	通常
VIPER	✅⭐️	✅⭐️	❌

紧耦合MVC

举一个例子，在一个多页面的网页Web应用程序中，当你点击一个连接导航至其余页面的时候，该页面就会被所有从新加载。该架构的问题在于视图（View）与控制器（Controller）和模型（Model）是紧密耦合的。

Cocoa MVC

Cocoa MVC 是苹果公司建议iOS开发者使用的架构。理论上来讲，该架构能够经过控制器（Controller）将模型（Model）与视图（View）剥离开。

然而，在实际操做过程当中，Cocoa MVC 鼓励大规模视图控制器的使用，最终使得视图控制器完成全部操做。

尽管测试这样的耦合大规模视图控制器是十分困难的，然而在开发速度方面，Cocoa MVC是现有的这些选择里面表现最好的。

MVP

在MVP中，Presenter与视图控制器（view controller）的生命周期没有任何关系，视图能够很轻易地被取代。咱们能够认为UIViewController实际上就是视图（View）。

还有另一种类型的MVP：带有数据绑定的MVP。以下图所示，视图（View）与模型（Model）和控制器（Controller）是紧密耦合的。

MVVM

MVVM与MVP类似不过MVVM绑定的是视图（View）与视图模型（View Model）。

VIPER

不一样于MV(X)的三层结构，VIPER具备五层结构（VIPER View, Interactor, Presenter, Entity, 和 Routing）。这样的结构能够很好地进行职责分配可是其维护性较差。

相较于MV(X)，VIPER有下列不一样点：

1. Model 的逻辑处理转移到了 Interactor 上，这样一来，Entities 没有逻辑，只是纯粹的保存数据的结构。
2. UI相关的业务逻辑分在Presenter中，数据修改功能分在Interactor中。
3. VIPER为实现模块间的跳转功能引入了路由模块 Router 。

本文首发于硅谷io