简而言之，在MVC控制器中，ViewModel知道(控件)视图，而在MVVM中，ViewModel不知道谁使用它。ViewModel将其可观察属性和操作公开给任何可能对使用它感兴趣的人。这一事实使得测试更容易，因为在ViewModel中没有对UI的引用。

一般来说，MVC用于Web开发，MVVM在WPF/Silverlight开发中最受欢迎。 然而，有时web架构可能混合使用MVC和MVVM。

例如:你可能会使用knockout.js，在这种情况下，你的客户端上会有MVVM。 你的MVC的服务器端也可以改变。在复杂的应用程序中，没有人使用纯模型。使用ViewModel作为MVC的“模型”可能有一定的意义，而你真正的模型基本上将是这个VM的一部分。这为您提供了一个额外的抽象层。

MVVM模型-视图视图模型类似于MVC，模型-视图控制器

控制器被替换为ViewModel。ViewModel位于UI层下面。ViewModel公开视图所需的数据和命令对象。你可以把它想象成一个容器对象视图从它那里获取数据和动作。ViewModel从模型中提取数据。

Russel East写了一篇博客，详细讨论了为什么MVVM不同于MVC

简而言之，在MVC控制器中，ViewModel知道(控件)视图，而在MVVM中，ViewModel不知道谁使用它。ViewModel将其可观察属性和操作公开给任何可能对使用它感兴趣的人。这一事实使得测试更容易，因为在ViewModel中没有对UI的引用。

让我惊讶的是，这是一个投票很高的答案，却没有提到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一起工作。