MVVM 不是那么好

概述作者：Soroush Khanlou，原文链接，原文日期：2015-12-17 译者：zltunes；校对：Channe；定稿：shanks 我写过许多关于让 ViewController 变得更轻量的文章，Model-View-ViewModel 是一种常用的可以实现该目的的设计模式。我觉得 MVVM 是一种反人类的设计模式，它使架构更加混乱而非清晰。View Model的命名很糟糕，它只是架构

作者：Soroush Khanlou，原文链接，原文日期：2015-12-17
译者：zltunes；校对：Channe；定稿：shanks

我写过许多关于让 VIEwController 变得更轻量的文章，Model-VIEw-viewmodel 是一种常用的可以实现该目的的设计模式。我觉得 MVVM 是一种反人类的设计模式，它使架构更加混乱而非清晰。VIEw Model的命名很糟糕，它只是架构优化的权宜之计。对我们来说放弃这一模式反而更好。

MVVM 命名很糟糕

名称是很重要的。一个理想的名称能够有效地传达出对象是干什么的，扮演什么角色以及怎么使用它。VIEw Model这一名称则没有发挥任何作用。

在我看来，VIEw Model这个十分抽象的名称实际上指的是两个截然不同的设计模式。

VIEw Model的第一种含义是 model for the vIEw（视图的模型）。这是一个愚蠢的对象（严格来讲 Swift 中叫struct），用来传递给某个视图去填充它的子视图。它不应该包含任何逻辑或方法。类似于UILabel需要一个字符串，UIImageVIEw 需要一张图像，ProfileVIEw需要一个Profileviewmodel。该对象直接传递给ProfileVIEw，它允许你的子视图是私有的而非暴露给外界，这是很有用的一点。我更喜欢把这种设计模式叫做vIEw data，因为它把自己从vIEw model的另一种定义的包袱中除去了。

VIEw model另一种含义是介于模型和视图控制器之间的一种模糊、抽象的对象。负责将数据传递给表示层，有时候也作为网络和数据库通道，或者表单验证以及其他类似的任务。这种“万金油”式的对象可以为你的控制器减压，但往往最后会成为一个新的“下水道”，什么任务都往里面堆。

MVVM 引进太多职责

命名不够具体，导致这个类的任务无休止地增长。到底哪些任务应该交给vIEw model？没有人知道，好像什么都能交给它。

让我们看一些例子。

这里将网络请求放入vIEw model，并建议你添加验证和表示的逻辑。

这里只展示了如何将表示逻辑放到vIEw model中，并提出为什么不把它命名为Presenter的问题。

这里讲到用vIEw model上传数据并绑定到ReactiveCocoa。

这里用vIEw model进行验证和获取数据。

这里明确建议你在vIEw model中放入“其他代码”:

vIEw model 非常适合干这些事：验证逻辑、用户输入、视图展示逻辑、网络请求以及其他代码。

没有人知道vIEw model到底是什么意思，所以无法就“哪些功能交给 vIEw model”达成一致。它本身概念过于抽象。这些作者对一个 ValIDator 类、Presenter 类或者 Fetcher 类该做什么是没有异议的，这些名字都起得很好，能准确传达出对应类扮演的角色。

给用途截然不同的对象起同一个名字只能给读者造成困惑。如果我们不能就vIEw model的功能达成一致，为什么要给他们起这个名字？

这种看法面临着一个类似的挑战，我们发现controller这个名称同样太宽泛，无法包含一系列确切的任务。

你自己的类叫什么名字完全由你决定，选个好听的就是了！

MVVM 不改变你的架构

vIEw model 并不能从根本上改变你的应用程序的架构。这两张图有什么不同（原图）？

不需要利用先进的图片理论你也能看出这两张图几乎是一样的。

我能想到的 MVVM 模式最大的好处就是它把“下水道”从苹果自带的 vIEw controoller类转移到了vIEw model这一自定义的对象。vIEw controller只需要专注于视图生命周期事件即可，变得很简洁。尽管如此，还是有“下水道”存在，仅仅是转移了而已。

由于vIEw model只是给 app 添加的一层定义简陋的模块，仍无法解决复杂性的问题。如果你为了避免vIEw controller过于臃肿而创建了vIEw model，那么当你的代码规模加倍的时候会发生什么？也许我们可以加一个controller-model层。

vIEw model方案不能大规模扩张。对于它想解决的问题来说只能做到缓解而无法完全避免。我们需要一个更佳的方案，比如可以尝试随着一个对象的增大不断去分解它，像细胞进行有丝分裂一样。VIEw model只是权宜之计。

其他社区也曾面临该问题

几年前 Rails 社区也曾遇到这种问题，他们也想出了解决方案，我们可以从中获得一些启示。首先他们有臃肿的controller以及几乎没什么内容的model。这种情况下很难进行测试，所以把所有的逻辑代码分解到model中，最终controller变得很简洁，model变得臃肿。复杂的model依赖于ActiveRecord和数据库，依旧难以测试，仍需要继续分割成更小的部分。

7 Patterns to Refactor Fat ActiveRecord Models 这篇博客受到8 Patterns to Help You Destroy Massive View Controller的影响，是这一系列想法下的产物。总而言之你仍需要将那些恼人的东西分割成小的单元，“转移下水道”的做法仅是缓解之计。

vIEw model是一种完全无法应对现代编程挑战的做法，命名糟糕，对自己包含的功能不明确，最终面临和controller一样的问题。它只是对复杂情形的权宜之计，如果我们不去避免这种做法，很快又会面临同样的问题。

本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 http://swift.gg。

总结

以上是内存溢出为你收集整理的MVVM 不是那么好全部内容，希望文章能够帮你解决MVVM 不是那么好所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。