iOS开发之进阶篇——MVC/MVP/MVVM/VIPER 架构

概述

本文基本转译自这篇博文 iOS Architecture Patterns.

事实上, 网上大多数关于讨论这几个架构的博文, 均出自于此.

本文将惜字如金般、直截了当地抛论点, 上代码.

祝各位看官阅读愉快!!

如题, 我们将对 这四个常用iOS架构进行一一讨论.

先来看看它们之间的综合对比:

图中三个对比要素分别为:

各实体(指等)之间均摊职责

代码可测试性

易于使用

我们统称为派别. 其中均由发展而来, 是为了将Controller瘦身而发展成不同的产物. 我们将这三者进行归纳讨论:

Models— 负责操纵数据(本地或远端), 或指代操纵数据的数据访问层.

Views— 负责展示内容的视图. 如UIImageView, UILabel等带UI开头的内容.

Controller/Presenter/ViewModel— View和Model之间的连接"桥梁", 负责将View中的用户行为(如点击某个button)转变为Model, 也将Model的改变通过View表现出来.

有点不同, 它不属于类别. 对职责分离的想法进行了另一次迭代, 将整个架构划分为五个层级, 使得职责的划分更为细致. 对于这五个层级, 我们在后文中再根据图示来一一讨论.

MVC

图中, 上半部分是苹果所期望的MVC的样子, 但由于View和View Controller过度耦合, 导致了实际上我们的MVC的样子看起来更像下半部分.

三要素:

Distribution— 和虽然分离, 但和紧耦合.

Testability— 易于测试, 而和难以测试.

Ease of use— 相较于其他架构, 代码量最小.

MVP

三要素:

Distribution— 职责划分明确

Testability— 可测试性非常好, 虽然是以使用笨拙的View(VC)作为代价.

Easy of use— 代码量是MVC的两倍. 但MVP概念清晰.

MVVM

三要素:

Distribution— MVVM的View的责任比MVP的View的责任更大

Testability— View Model不关心View的实现, 因此易于测试

Easy of use— MVVM的代码量与MVP相当.

绑定

绑定对于OS X开发是开箱即用的，但是我们在iOS工具箱中没有绑定。当然，我们有KVO和通知，但它们不如绑定方便。

因此，如果我们不想自己编写它们，我们有两个选择：

基于KVO的绑定库之一，例如RZDataBinding或SwiftBond

全规模函数反应性编程巨兽，例如ReactiveCocoa，RxSwift或PromiseKit

VIPER

Interactor— 交互器. 包含与数据（实体）或网络相关的业务逻辑，例如创建实体的新实例或从服务器获取它们。为此，您将使用一些服务和管理器，这些服务和管理器不被视为VIPER模块的一部分，而是外部依赖项。

Presenter— 包含UI相关(但独立于UIKit)的业务逻辑，调用Interactor上的方法。

Entities— 普通数据对象，而不是数据访问层，因为这是交互者的职责。

Router— 负责VIPER 模块之间的隔离。

View— UI展示. 包括View和VC.

三要素:

Distribution— 职责分配最优者 (相较于另外三种架构).

Testability— 最好的可测试性 (相较于另外三种架构).

Easy of use— 代码量巨大 (接口多).

结语

大胆地在同一工程中混合使用不同的MV(X)架构, 它们本身的兼容性很好.

根据业务需求选择架构, 不要为了架构而架构.

没有最好的架构, 只有最合适的架构.