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

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

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

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

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

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

我认为要理解这些首字母缩略词的意思，最简单的方法就是暂时忘掉它们。相反，想想它们源自的软件，每一个软件。这实际上可以归结为早期网络和桌面之间的区别。

在2000年代中期，随着复杂性的增长，MVC软件设计模式(在20世纪70年代首次被描述)开始应用于web应用程序。想想数据库、HTML页面和中间的代码。让我们稍微改进一下以达到MVC:对于»database«，让我们假设数据库加接口代码。对于»HTML页面«，让我们假设HTML模板加上模板处理代码。对于»code inbetween«，让我们假设代码将用户单击映射到操作，可能会影响数据库，肯定会显示另一个视图。就是这样，至少为了比较的目的是这样的。

让我们保留这个网页的一个特性，不是像今天那样，而是像十年前那样，当时JavaScript还是一个低级的、卑鄙的烦恼，真正的程序员很好地避开了:HTML页面本质上是愚蠢和被动的。浏览器是一个瘦客户机，或者可以说是一个穷客户机。浏览器中没有智能。整页重载规则。每次都会重新生成»view«。

让我们记住，尽管这种网络方式风靡一时，但与桌面相比，它是非常落后的。桌面应用程序是胖客户端，也可以说是富客户端。(甚至像Microsoft Word这样的程序也可以被视为某种客户端，文档客户端。)他们是充满智慧的客户，对自己的数据了如指掌。他们是有状态的。它们在内存中缓存正在处理的数据。没有整页重载这种废话。

这种富桌面方式可能就是第二个首字母缩写MVVM的起源。不要被字母所迷惑，也不要被c的省略所迷惑。他们必须如此。没有东西被移除。我们只增加了一件事:状态性，缓存在客户端上的数据(以及处理这些数据的智能)。该数据(本质上是客户机上的缓存)现在被称为»ViewModel«。它允许丰富的交互性。就是这样。

MVC =模型、控制器、视图=本质上的单向通信=交互性差 MVVM =模型、控制器、缓存、视图=双向通信=丰富的交互性

我们可以看到，通过Flash、Silverlight，以及最重要的JavaScript, web已经拥抱了MVVM。浏览器不能再被合法地称为瘦客户机。看看它们的可编程性。看看他们的内存消耗。看看现代网页上所有的Javascript交互。

就我个人而言，我发现这个理论和缩略语业务更容易理解，看看它在具体现实中指的是什么。抽象的概念是有用的，特别是在具体的问题上，所以理解可能会有一个完整的循环。

我认为主要的区别之一是，在MVC中，你的V直接读取你的M，并通过C来操作数据，而在MVVM中，你的VM充当M代理，以及为你的V提供可用的功能。

如果我不是满口废话，我很惊讶没有人创建一个混合的，其中您的VM只是一个M代理，C提供所有功能。

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