让我惊讶的是，这是一个投票很高的答案，却没有提到MVVM的起源。MVVM是微软社区常用的术语，它起源于Martin Fowler的表示模型。所以要了解这个模式的动机以及与他人的不同之处，首先要阅读关于这个模式的原文。

我曾经认为MVC和MVVM是一样的。现在，由于Flux的存在，我可以分辨出其中的区别:

在MVC中，对于你应用中的每个视图，你都有一个模型和一个控制器，我称之为视图，视图模型，视图控制器。该模式并没有告诉您一个视图如何与另一个视图通信。因此，在不同的框架中有不同的实现。例如，在某些实现中，控制器之间相互通信，而在其他实现中，有另一个组件在它们之间进行中介。甚至还有视图模型相互通信的实现，这打破了MVC模式，因为视图模型应该只由视图控制器访问。

在MVVM中，每个组件都有一个视图模型。该模式没有指定视图应该如何影响视图模型，所以通常大多数框架只在视图模型中包含控制器的功能。但是，MVVM确实告诉您，视图模型的数据应该来自模型，这是整个模型，它不知道或自定义特定的视图。

为了说明差异，让我们以Flux模式为例。Flux模式告诉我们应用中的不同视图应该如何通信。每个视图侦听一个存储，并使用分派器触发操作。分派程序依次将刚刚执行的操作告知所有存储，然后存储更新自己。Flux中的存储对应于MVVM中的(通用)模型。它不是针对任何特定视图定制的。所以通常当人们使用React和Flux时，每个React组件实际上都实现了MVVM模式。当一个动作发生时，视图模型调用分派器，最后它根据存储(即模型)中的变化得到更新。你不能说每个组件都实现了MVC，因为在MVC中只有控制器才能更新视图模型。因此MVVM可以和Flux一起工作(MVVM处理视图和视图模型之间的通信，Flux处理不同视图之间的通信)，而MVC不能在不破坏关键原则的情况下与Flux一起工作。

MVVM

视图➡视图模型➡模型

视图有对ViewModel的引用，反之则没有。 ViewModel有对模型的引用，反之则没有。 视图没有对模型的引用，反之亦然。

如果你正在使用一个控制器，它可以有一个视图和视图模型的引用，尽管控制器并不总是必要的，就像在SwiftUI中演示的那样。 数据绑定:我们为ViewModel属性创建侦听器，这样数据就可以通过视图模型从视图流向模型。虽然这些引用是单向的:View↔ViewModel↔Model，但数据需要流动:View↔ViewModel。视图如何通过读取自己的属性从模型中获取数据是很清楚的。数据绑定是如何在视图中检测事件并将它们反馈给模型。

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.viewColor
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }
   
   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

设置的差异

业务逻辑保存在MVC的控制器中，MVVM的ViewModels中。 在MVC中，事件直接从视图传递到控制器，而在MVVM中，事件从视图传递到ViewModel再到控制器(如果有的话)。

共同的特征

MVVM和MVC都不允许视图直接向模型发送消息。 两者都有自己的模型。 两人都有自己的观点。

MVVM的优点

因为viewmodel包含业务逻辑，所以它们是更小的具体对象，便于进行单元测试。另一方面，在MVC中，业务逻辑在ViewController中。如果不同时测试所有的方法和侦听器，你怎么能相信视图控制器的单元测试是全面安全的呢?您不能完全相信单元测试结果。 在MVVM中，由于业务逻辑从控制器中被抽取到原子ViewModel单元中，ViewController的大小缩小了，这使得ViewController代码更加清晰。

MVC的优点

在控制器中提供业务逻辑减少了对分支的需求，因此语句更有可能在缓存上运行，这比将业务逻辑封装到ViewModels中性能更好。 在一个地方提供业务逻辑可以加速不需要测试的简单应用程序的开发过程。我不知道什么时候不需要检查。 对于新开发人员来说，在ViewController中提供业务逻辑更容易考虑。

视图模型是用户界面元素的“抽象”模型。它必须允许您以非可视的方式(例如测试)在视图中执行命令和操作。

如果你使用过MVC，你可能有时会发现创建模型对象来反映视图的状态很有用，例如，显示和隐藏一些编辑对话框等。在这种情况下，您使用的是视图模型。

MVVM模式只是将该实践推广到所有UI元素。

而且这不是微软的模式，WPF / Silverlight数据绑定特别适合使用这种模式。但是没有什么能阻止您使用它与java服务器面，例如。

微软在这里提供了Windows环境中MVVM模式的解释。

这里有一个关键的部分:

在模型-视图-视图模型设计模式中，应用程序由以下部分组成 三个一般组成部分。 模型:这表示应用程序使用的数据模型。例如，在图片共享应用程序中，此层可能表示 设备上可用的图片集和用于读取和的API 写入图片库。 视图:应用通常由多个UI页面组成。显示给用户的每个页面都是MVVM术语中的一个视图。观点是 用于定义和设置用户所看到内容样式的XAML代码。的数据 从模型显示到用户，这是工作的 的当前状态为UI提供此数据 例如，在一个图片共享应用中，视图就是UI 向用户显示设备上的相册列表，其中的图片 一个相册，或者另一个向用户显示特定信息的相册 图片。 ViewModel: ViewModel将数据模型或简单的模型绑定到应用程序的UI或视图上 哪一个来管理模型中的数据并将数据作为一个集合公开 XAML UI或视图可以绑定到的属性。例如, 在图片共享应用中，ViewModel会显示一个相册列表， 并且为每个相册公开一个图片列表。UI是不可知论的 图片从何而来，如何获取。它只是 知道ViewModel所显示的一组图片，并显示它们 对用户。

MVVM是表示模型模式的改进(有争议)。我说有争议，因为唯一的区别是WPF如何提供数据绑定和命令处理的能力。