MVVM没你想象的那么的好

2016-01-16 19:20:22 | 来源：玩转帮会 | 投稿：佚名 | 编辑：小柯

原标题：MVVM没你想象的那么的好

本文由cocoaChina译者陈溪翻译
作者：Soroush Khanlou
原文：MVVM is Not Very Good

我写过很多有关于让View Controller 更易于理解的文章，其中一种比较常见的模式就是Model-View-ViewModel(MVVM)。我认为MVVM 是一种非常容易让人混淆的 anti-pattern(反面模式设计）。View models是很糟糕的名字，它只是优秀架构之路上的权宜之计。我们的团体将从这种模式过度到更好的模式。

MVVM 是一个很糟糕的名字

名字很重要。理想的情况下，一个名字能够有效地表达这个对象是什么，它扮演了什么样的角色，以及如何使用它等。View model作为一个名字，没有起到任何的作用。

以我的经验来看，考虑到view model的抽象性，它实际上代表了两种迥然不同的模式

第一种 “view model” 是 “model for the view”。这是一个dumb object(在Swift中绝对是一个结构体) 用来传递 view 给它的子视图。它不应该包含任何逻辑甚至是任何方法。这跟UILabel包含string，或者UIImageView包含Image，自定义profileView包含profileViewModel 是一样的道理。它直接传递给你的ProfileView，最重要的是，它允许你将子视图私有化，而不是将子视图暴露在外面。这是一个非常好的方法。我见过一种叫 view data 的模式，我非常喜欢这种模式，因为它将自己从定义模糊不清的”view model” 中剥离出来了。

View model 同时也一种介于model object和view controller之间模糊的、抽象的名词。它处理数据展示、网络请求获取数据、表单验证和你认为可以放在这里的其他任务。这种万金油风格的对象主要用来减轻控制器的压力。但是最终，你只是多建立了一个能够让你将任务分工倒进去的容器。

MVVM 承担了更多的责任

这种缺乏具体内涵的名字导致了这个类负责的东西无限地增长。那么什么样的功能才应该放在 view model 中呢？没人知道！随便写就是了。

我们来看一些例子

Let’s discuss MVVM for iOS 这篇文章展示了view model 中的网络数据模型，推荐你在里边添加验证和展示逻辑。
Introduction to MVVM 这篇文章展示了如何将表示逻辑放入视图模型中，同时引发了一个问题–为什么它不叫 Presenter?
COCOA SAMURAI?这篇告诉你应该用view model来上传数据并绑定ReactiveCocoa.
ReactiveCocoa and MVVM, an Introduction 这篇使用view model 来表格验证和获取数据。
Model-View-ViewModel for iOS 这篇文章特别建议你将“miscellaneous code”(“无法明确定义的代码”) 放入到view model 中。

View Model非常适用于存放用户输入的验证逻辑，视图的表示逻辑, 网络请求的初始化和其它“miscellaneous code ”的地方。

没人知道“view model”代表着什么，所以人们无法在view model 应该包含什么内容这一问题上达成一致。view model 这个概念本身就太抽象了。这些作者在Validator class、Presenter class 或者 Fetcher class 该做哪些事和不该做哪些事上有不同的观点。这些都是有着明确定义的好名字。

假设一个同样的名字，在不同的对象中有着迥然不同的任务分工，那么它只会混淆读代码的人。如果我们无法在view model 的作用上达成一致，那么将这些不同作用的“view model”取成同一个名字又由什么好处呢？

我们已知的规律中已经面临了一个同样的挑战，并且我们发现“controller”的名字定义太广泛了，它能够包含很多小的任务 .

你完全可以给你自己的类定义一个你想要的名字！选一个好点的名字

MVVM并没有改变你代码的结构

最后，view models 本质上并没有改变你app的结构。这两幅图有什么区别？(source）

你不需要高级的图形理论就可以看出他们基本上是完全一样的。

我所知道这个模式最清楚的地方就是: 它将view controller 中的(view controller不是一个你拥有的对象，因为它是Apple class 的一个子类) 代码移动到了你拥有的view model 中。这样view controller 就很容易的能够聚焦view生命周期时间。尽管这样，我们的代码还是大量的聚集在一起，它只是从view controller 移动到了 view model 中而已。

因为view model 只有一个，我们还没有解决这个复杂的问题。如果你创建一个view model 来避免你的控制器过于臃肿，那么如果你的app代码又增加了一倍要怎么办？或许到那时候，我们可以加一个controller-model.

这种view model 解决方法不是很好，它只是在问题上贴了一个创可贴，问题还会继续出现。我们需要一个更好的，能从根本上解决问题的办法。就像一个能够在对象变得更大时，你能够对其进行持续性的划分，好比正在进行有丝分裂的细胞。view model它只是个一次性的补丁。

其他的团体已经经历过这样的问题

Rails community 在几年前就经历过这个问题，我们能够从他们的故事中有所借鉴。首先，他们controller非常臃肿 ,除了persistence(持久性数据）外,几乎是一个空的模型。这样的代码几乎无法测试，于是他们将所有的逻辑移动到了model中，这样就有了简洁的controller和臃肿的model。由于臃肿的model依靠于ActiveRecord, 这样的话数据库依旧很难测试并且需要拆分成很小的单元。

博客里面已经贴出了像 7 Patterns to Refactor Fat ActiveRecord Models 这篇文章 (给了我写8 Patterns to Help You Destroy Massive View Controller这篇文章的灵感），这是上述思维方式的产品例子。最终，你将持续将你的核心分割成小的单元，那么移动你的代码时就能够有效的划分到对应的区域。

View model作为一种解决方法，并不适用于现代编程模式的变化。他们是一种定义不清的结构，不知道应该包含什么，这就导致了它们会遇到和view controller 一样的问题。它们只是当我们遇到复杂问题的临时补丁，如果我们忽略这些问题，在不久之后问题再次出现时，我们还是要解决同样的问题。