MVVM 这个模式可能大家耳朵都听出茧了，但却没有多少人真正在项目中应用过，毕竟 Cocoa Touch 整体是基于“MVC”的，没有 Controller 根本干不了活。而且这年头虽然各种 buzz word 盛嚣尘上，但不同领域的人对它们都有不同的理解，看多了说多了自己都有点烦。我今天也不想说到底什么是 MVC，什么是 MVVM，这些我之前在这篇文章有提过一点。如果大家真的对它们的原始定义感兴趣，可以看看这篇 MVC 论文，四人帮的《设计模式》也对 MVC 有所阐述；MVVM 的话我们知道它是微软在推出 WPF 时提出的，可以看看 MSDN 的相关博客。
言归正传，今天我主要想谈谈自己对 ViewModel 的一些理解。因为我们不一定要完全照搬某种模式，取其精华然后根据具体项目情况进行应用也挺好的。ViewModel 这个概念我就觉得蛮精华的。我们都知道 ViewModel 跟 View 是绑定的关系，那究竟怎么绑定呢？有几种方案：
- UI 布局尽量用 IB 来做，把绑定逻辑放到 View 中
- 把绑定逻辑放到 Model 中
- 定义单独的 ViewModel 加工 Model，并把适合展示的数据输出给 View
以上这几种方案主要说的是数据绑定，而且都是单向绑定，实际上 ViewModel 还可以跟 View 进行双向数据绑定、逻辑绑定等，这些先按下不表，下面举个例子分别说说这三种单向数据绑定的实现以及优缺点。
上图是我正在写的一个 Github 客户端的 Profile 页面，它的头部是一个单独的 View，包含了一些 UI 元素：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
class ProfileHeader: UIView { @IBOutlet var contentView: UIView! @IBOutlet weak var backgroundView: UIImageView! @IBOutlet weak var avatarView: UIImageView! @IBOutlet weak var followersButton: UIButton! @IBOutlet weak var repositoriesButton: UIButton! @IBOutlet weak var followingButton: UIButton! @IBOutlet weak var nicknameLabel: UILabel! @IBOutlet weak var bioLabel: UILabel! // ... } |
通过网络请求拿到相关数据之后，怎么传递给这些 UI 元素来显示呢？当然我们可以放到 Controller 中，只不过 Controller 会变得非常臃肿。那我们就来尝试以上三种方案。
方案一：View 作为 ViewModel
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
protocol ViewModelType { associatedtype Model func bind(model: Model) } extension ProfileHeader: ViewModelType { func bind(model: Profile) { let avatarURL = NSURL(string: model.avatar) backgroundView.presentImageAnimated(avatarURL) avatarView.presentImageAnimated(avatarURL) nicknameLabel.text = model.login bioLabel.text = model.bio ?? "Not set yet" let attributedFollowers = (title: "\(model.followers) \nFollowers", attributingTitle: "Followers") let attributedRepositories = (title: "\(model.repos) \nRepositories", attributingTitle: "Repositories") let attributedFollowing = ("\(model.following) \nFollowing", attributingTitle: "Following") followersButton.setAttributedTitle(attributedFollowers) repositoriesButton.setAttributedTitle(attributedRepositories) followingButton.setAttributedTitle(attributedFollowing) } } |
这个是我以前比较喜欢的做法，优点是简洁明了，没有太多弯弯绕绕的东西，基本就是把原本写在 Controller 中的代码放到了 View 中。缺点也非常明显，就是这个“绑定”实在是绑得太死了，直接就写在了 View 里，那这个 View 基本就不能复用了。假设在另一个页面也有一个 Header，UI 跟这个ProfileHeader一样，展示的数据也是来自Profile这个 Model，但是展示的方式不一样，譬如nicknameLabel需要显示 Nickname: XXX，其它 UI 元素也需要加点附加信息什么的，那这个时候就很尴尬了。只能新建一个NewHeader，把之前的 xib 文件 copy 过来，把 class 改成NewHeader，把各个 label 啊 button 啊拉线拉过来，然后写一个新的bind方法。如果ProfileHeader中有很多其它的辅助方法，在NewHeader中也要用到，那NewHeader就得继承ProfileHeader，然后重写bind方法……所以这种方案啊，是不太科学的……想必你也发现了，这种情况下，ViewModelType这个协议，其实并没有什么卵用。用协议作为类型，往往可以提供更大的灵活性和可扩展性，但是如果是由 View 来实现这个协议，由于 View 已经是数据流的终点了，一旦把处理数据的逻辑写在这里，就不存在什么替换的可能了，这个协议也就只是作为一个限制或者说标识了——一旦别人看到某个 View 实现了这个协议，就知道这个 View 内部有处理数据的逻辑。但按这个思路的话，其实基本每个 View 都需要处理数据，也就都需要实现这个协议。所以这个协议其实是可有可无的，它的存在除了让代码显得更“面向协议（POP）”一些，并没有带来太多实质性的好处。
方案二：Model 作为 ViewModel
这种方案我在一个演讲中看到过，思路也很简单，跟方案一恰恰相反，不是把 Model 注入 View 中，而是把 View 注入 Model 中，还是以 Profile 为例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 5926c2f537993063-49">49 50 51 52 53 MVVM，这些我之前在这篇文章有提过一点。如果大家真的对它们的原始定义感兴趣，可以看看这篇 MVC 论文，四人帮的《设计模式》也对 MVC 有所阐述；MVVM 的话我们知道它是微软在推出 WPF 时提出的，可以看看 MSDN 的相关博客。
言归正传，今天我主要想谈谈自己对 ViewModel 的一些理解。因为我们不一定要完全照搬某种模式，取其精华然后根据具体项目情况进行应用也挺好的。ViewModel 这个概念我就觉得蛮精华的。我们都知道 ViewModel 跟 View 是绑定的关系，那究竟怎么绑定呢？有几种方案：
以上这几种方案主要说的是数据绑定，而且都是单向绑定，实际上 ViewModel 还可以跟 View 进行双向数据绑定、逻辑绑定等，这些先按下不表，下面举个例子分别说说这三种单向数据绑定的实现以及优缺点。
Profile.png
上图是我正在写的一个 Github 客户端的 Profile 页面，它的头部是一个单独的 View，包含了一些 UI 元素：
通过网络请求拿到相关数据之后，怎么传递给这些 UI 元素来显示呢？当然我们可以放到 Controller 中，只不过 Controller 会变得非常臃肿。那我们就来尝试以上三种方案。 方案一：View 作为 ViewModel
这个是我以前比较喜欢的做法，优点是简洁明了，没有太多弯弯绕绕的东西，基本就是把原本写在 Controller 中的代码放到了 View 中。缺点也非常明显，就是这个“绑定”实在是绑得太死了，直接就写在了 View 里，那这个 View 基本就不能复用了。假设在另一个页面也有一个 Header，UI 跟这个 方案二：Model 作为 ViewModel这种方案我在一个演讲中看到过，思路也很简单，跟方案一恰恰相反，不是把 Model 注入 View 中，而是把 View 注入 Model 中，还是以 Profile 为例：
|
