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()
}
复制代码

数据流：

• View 把本身做为 view model 的 delegate.
• 用户点击并重载.
• View 调用 view model 的 fetchMovies 方法.
• 数据获取成功后，view model 通知 delegate(view).
• 调用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()
}
复制代码

数据流：

• View 把本身做为 Presenter 的 delegate.
• Presenter 把本身做为 view model 的 delegate.
• 用户点击并重载.
• View 调用 presenter的 reload 方法.
• Presenter 调用 view model 的 fetchMovies 方法.
• 数据获取成功后，view model 通知 delegate(presenter).
• 调用updateWithMovies 并将电影对象转化为展现用的数据并通知 delegate(view).
• View 更新本身.

这意味着咱们能够经过让任何 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，在自身规则上作了更多的限制，使得不论什么水平的开发者在遵循这些规则进行业务开发后，代码质量可以保持在一个相对不错的水平。

所以在我看来，选择怎样的架构模式取决于团队的平均能力，大致上来讲，团队能力能够和架构模式的规则数量成反比。

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