VIPER 和 MVVM 到底有什么区别

这篇博客主要的内容是译自Göksel Köksal 的 Blurring the Lines Between MVVM and VIPER （本文已获得作者的授权翻译），我把自己对于业务架构模式观点放在了文末，以下是译文：

如果你开发过移动端App，那你肯定听说过 MVVM 和 VIPER. 虽然有观点说MVVM的扩展性不够好，也有观点说VIPER是个过度设计的产物。而我在这里想说的是，它俩非常接近，甚至我们都没有必要去把它俩分开对待。

先来快速地过一遍 MVVM 和 VIPER.

什么是 MVVM？

• View 将用户行为传递给 view model .
• View model 处理这些行为并更新它们的状态.
• View model 接着通知 view , 这一步可以通过 数据绑定 或者 delegation 和 blocks 实现.

什么是 VIPER？

• View 将用户行为传递给 presenter .
• Presenter 将这些行为传递给 interactor 或 router .
• 如果行为需要做计算操作，由 interactor 处理并将状态返回给 presenter .
• Presenter 把这个状态转化为展示用的数据并更新 view .
• Router 则封装了导航逻辑，由 presenter 负责触发.

想了解更多关于这两种架构的内容，可以参考这篇牛逼的文章 Bohdan Orlov :  iOS Architecture Patterns *

我们的主要目标是什么？

首要的目标是将UI和业务逻辑分离。这样才可以在不破坏任何业务逻辑的情况下去更新UI，或者单独地去测试业务逻辑的代码。事实上MVVM和VIPER都可以达到这个目标，只是方式不一样而已。从这个角度来看的话，它俩的结构可以像下面这样：

MVVM的 UI 层只有一个 View 组件，而 VIPER 将 UI 层拆分成了三个组件：View, Presenter 和 Router. 而业务层显然两者基本差不多。 接下来我们通过例子看看他俩在 UI 层的区别。

一个虚构的App: TopMovies

假设我们要用 MVVM 做一个简单的 App: 把 IMDB 上 TOP 25 的电影数据拉下来并显示在一个列表中。 组件代码大概会是下面这样：

protocol MovieListView: MovieListViewModelDelegate {
  private var viewModel: MovieListViewModel
  func updateWithMovies(_ movies: [Movie])
  func didTapOnReload()
  func didTapOnMovie(at index: Int)
  func showDetailView(for movie: Movie)
}

protocol MovieListViewModelDelegate: class {
  func viewModelDidUpdate(_ model: MovieListViewModel)
}

protocol MovieListViewModel {
  weak var delegate: MovieListViewModelDelegate? { get set }
  var movies: [Movie] { get }
  func fetchMovies()
}

数据流：

fetchMovies
updateWithMovies

相当简单的一个逻辑对吧。接下来我们在 macOS 上创建一个基本相同的 App, 并尽可能多地复用代码。

假设场景：实现 macOS 版本

首先可以确定一件事，view 的类肯定是不一样的。因此我们没法复用 iOS App 中展示逻辑的代码。而 iOS 的 view 已经在 updateWithMovies 将电影对象转化成了展示用的数据，所以想要复用这部分逻辑的就只能它抽出来。我们把创建展示用的数据的代码挪到一个介于 view 和 view model 之间的中间类里， 这样就能在 iOS 和 macOS 的 view 里复用这部分代码了。 于是我们把这个中间类就叫 Presenter, 叫这个名字纯属偶然，和VIPER一毛关系都没有~

protocol MovieListView: MovieListPresenterDelegate {
  private var presenter: MovieListPresenter
  func didTapOnReload()
  func didTapOnMovie(at index: Int)
  func showDetailView(for movie: Movie)
}

protocol MovieListPresenterDelegate {
  func updateWithMoviePresentations(_ movies: [MoviePresentation])
}

protocol MovieListPresenter: MovieListViewModelDelegate {
  private var viewModel: MovieListViewModel
  func reload()
  func presentation(from movie: Movie) -> MoviePresentation
}

protocol MovieListViewModelDelegate: class {
  func viewModelDidUpdate(_ model: MovieListViewModel)
}

protocol MovieListViewModel {
  weak var delegate: MovieListViewModelDelegate? { get set }
  var movies: [Movie] { get }
  func fetchMovies()
}

数据流：

reload
fetchMovies
updateWithMovies

这意味着我们可以通过让任何 view 遵循 MovieListView 协议就能够跨平台实现上面的需求。 现在我们通过复用 iOS 项目大部分的代码实现了全新的 macOS App. 然而这个时候，苹果宣布了一个大事。。。

假设场景：iOS 重设计

几周后，苹果发布了iOS 26，Jone Ive 又双叒叕宣布了一个全新的设计系统。 我们的设计师看了以后贼兴奋并且也很快就搞了一套全新的设计稿出来。现在我们的工作变成了实现这套全新的UI，并确保可以用A/B testing来控制只让一部分用户显示这套UI。 我们这么优秀的工程师，这点改动不算啥对吧。我们只需要写一个新的 iOS view 并遵循 MovieListView

协议，然后绑定 presenter 就行了，简直不要太简单。

protocol MovieListView: MovieListPresenterDelegate {
  ...
  func didTapOnMovie(at index: Int)
  func showDetailView(for movie: Movie)
}

在实现这个新类的时候，我们会意识到 showDetailView 在新旧view的实现是一样的。我们可能会想到复制粘贴这部分代码，不过我们这么优秀的工程师，怎么可能允许复制粘贴代码对吧？ OK，我们把这部分逻辑也挪出来，并且把这个组件叫 Router, 同样，这个名字也是纯属偶然。

protocol MovieListRouter {
  func showDetailView(for movie: Movie)
}

Router 作为当前页面的代言人，负责在需要的时候显示对应的详情页。但是这个组件应该放在哪呢？放在新旧两版view里吗？听上去也可以不过就以往经验来看，除非确实需求发生变化，还是不要频繁改变 view 的代码比较好。 还是让我们把这个责任交给 presenter 吧，让它来持有 router. 这样当用户行为发生，presenter 接收到这个事件时，它可以决定是调用 view model 来做计算还是调用 router 来实现导航的功能。 现在我们把导航的逻辑也复用了，可以发版啦。 我们一起看看最终的代码结构：

protocol MovieListView: MovieListPresenterDelegate {
  private var presenter: MovieListPresenter
  func didTapOnReload()
  func didTapOnMovie(at index: Int)
}

protocol MovieListPresenterDelegate {
  func updateWithMoviePresentations(_ movies: [MoviePresentation])
}

protocol MovieListPresenter: MovieListViewModelDelegate {
  private var router: MovieListRouter
  private var viewModel: MovieListViewModel
  func reload()
  func presentation(from movie: Movie) -> MoviePresentation
}

protocol MovieListRouter {
  func showDetailView(for movie: Movie)
}

protocol MovieListViewModelDelegate: class {
  func viewModelDidUpdate(_ model: MovieListViewModel)
}

protocol MovieListViewModel {
  weak var delegate: MovieListViewModelDelegate? { get set }
  var movies: [Movie] { get }
  func fetchMovies()
}

看到这里，我想你应该 get 到了吧，这时候我们把 MovieListViewModel 改名为 MovieListInteractor 的话, 代码就变成了 100%的VIPER，但同时又没有违背 MVVM 的原则。

总结

软件架构说白了就是一堆的规则。有的架构规则多，有的规则少。使用一种架构并不意味着就是完全摒弃另外一种。尤其是当我们在讨论MVC, MVVM 和 VIPER的时候。

从左到右，是一个扩展性的演化，而不是前后矛盾。VIPER 是这三者当中的最细化的版本，这也是为什么很多人认为它是设计过度了，而且事实上我也觉得这些人的的批评是对的。 VIPER一共有5个组件，然而你却不一定在所有场景里都需要全部的5个组件。我认为我们在开发过程中应该把精力放在需求本身而不是盲目地去遵循一些设计规则。 对于 VIPER，我的建议是：

• 从 VIPER 的简化版开始，和 MVVM 基本差不多，只有 view, interactor 和 entities.
• 如果你希望快速修改UI， 就把 presenter 加进来.
• 如果你的项目里有复杂且可重用的路由逻辑，那就添加 router.
• 在实现每个需求之前，设计好类图和接口。尽管业界普遍认为这样做必要性不大但是绝对能帮你设计出更好的接口，并且最后来看能减少开发时间。

译者的总结：

关于VIPER，我在之前一直有所耳闻，但是因为没有在项目中实践过，对于细节实际上是一知半解的。这篇文章从一个非常好的角度分析了VIPER和MVVM的区别，我看完后收益颇丰。因此在这里将其翻译为中文，以便自己日后回顾。 对于架构模式，我自己的观点，和文中的观点非常类似，我认为项目中选择怎样的架构模式根本不重要，我们的目的只有一个，那就是解耦且易扩展。 被业界diss无数次的MVC，实际上在优秀的 程序员 手里，照样能够发挥得很好，但是到了一些相对初级的开发者那，则会有Massive Controller的问题，而这里面最主要的原因，我认为就是MVC制定的规则太少了。 资深一些的开发者，他们对软件架构的原则了解于心，因此不论架构模式的规则是多还是少，从他们手中产出的代码始终能维持在一个优雅的程度。因此，MVC在不同的人手中会有不同的结果。 而规则相对较多的MVVM，以及VIPER，在自身规则上做了更多的限制，使得不论什么水平的开发者在遵循这些规则进行业务开发后，代码质量能够保持在一个相对不错的水平。 因此在我看来，选择怎样的架构模式取决于团队的平均能力，大体上来说，团队能力可以和架构模式的规则数量成反比。

对于业务的架构模式有什么问题，欢迎一起讨论。