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

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

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

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

MVC/MVVM不是一个非此即彼的选择。

这两种模式以不同的方式出现在ASP。Net和Silverlight/WPF开发。

ASP。Net, MVVM用于视图内的双向绑定数据。这通常是一个客户端实现(例如使用Knockout.js)。另一方面，MVC是一种在服务器端分离关注点的方法。

对于Silverlight和WPF来说，MVVM模式包含的内容更广泛，可以作为MVC(或其他将软件组织成独立职责的模式)的替代品。这种模式中经常出现的一个假设是，ViewModel简单地取代了MVC中的控制器(就好像你可以用VM代替C的首字母缩写一样，一切都可以原谅)……

ViewModel并不一定会取代对独立控制器的需求。

问题是:为了能够独立测试*，特别是在需要时可重用，视图模型不知道是什么视图显示了它，但更重要的是不知道它的数据来自哪里。

*注意:在实践中，控制器从ViewModel中删除了大部分需要单元测试的逻辑。VM就变成了一个不需要测试的容器，只需要很少的测试。这是一件好事，因为VM只是设计师和编码器之间的桥梁，所以应该保持简单。

即使在MVVM中，控制器也通常包含所有的处理逻辑，并决定使用哪个视图模型在哪个视图中显示哪些数据。

到目前为止，我们已经看到ViewModel模式的主要好处是从XAML后台代码中删除代码，从而使XAML编辑成为一个更加独立的任务。当需要时，我们仍然创建控制器来控制(没有双关语)应用程序的整体逻辑。

我们遵循的基本MVCVM指南是:

视图显示数据的特定形状。他们不知道数据从何而来。 ViewModels保存着特定形状的数据和命令，它们不知道数据或代码来自哪里，也不知道它是如何显示的。 模型保存实际数据(各种上下文、存储或其他方法) 控制器监听并发布事件。控制器提供了控制在哪里看到什么数据的逻辑。控制器为ViewModel提供命令代码，以便ViewModel实际上是可重用的。

我们还注意到，Sculpture代码生成框架实现了MVVM和类似于Prism的模式，它还大量使用控制器来分离所有用例逻辑。

不要认为控制器已经被视图模型淘汰了。

我已经开始了一个关于这个主题的博客，当我可以的时候，我会添加进去(只有当主机丢失时存档)。将MVCVM与通用导航系统相结合存在一些问题，因为大多数导航系统只使用视图和vm，但我将在后面的文章中讨论这个问题。

使用MVCVM模型的另一个好处是，在应用程序的生命周期中，只有控制器对象需要存在于内存中，并且控制器主要包含代码和少量的状态数据(即很小的内存开销)。与需要保留视图模型的解决方案相比，这大大减少了应用程序的内存密集型，并且非常适合某些类型的移动开发(例如使用Silverlight/Prism/MEF的Windows mobile)。这当然取决于应用程序的类型，因为您可能仍然需要保留偶尔缓存的虚拟机来响应。

注意:这篇文章已经编辑了很多次，并没有特别针对所提出的狭窄问题，所以我更新了第一部分，现在也包括了这个问题。在下面的评论中，大部分讨论只与ASP有关。而不是更广阔的图景。本文旨在介绍MVVM在Silverlight、WPF和ASP中的广泛使用。Net，并试图阻止人们用ViewModels替换控制器。

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

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

从实用的角度来看，MVC(模型-视图-控制器)是一种模式。然而，当MVC作为ASP.net MVC使用时，当与实体框架(EF)和“强大的工具”相结合时，它是一种非常强大的、部分自动化的方法，用于将数据库、表和列引入web页面，用于完整的CRUD操作或仅用于R(检索或读取)操作。至少在我使用MVVM时，视图模型与依赖于业务对象的模型交互，这些业务对象是“手工制作”的，经过大量的努力，能够获得与EF提供的“开箱即用”一样好的模型是很幸运的。从实用编程的角度来看，MVC似乎是一个不错的选择，因为它提供了许多开箱即用的实用程序，但仍然有可能添加一些花哨的功能。

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

在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交互。

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

在MVVM中，控制器不会被ViewModel取代，因为ViewModel的功能与控制器完全不同。你仍然需要一个控制器，因为如果没有控制器，你的模型、视图模型和视图就做不了什么…在MVVM中你也有一个控制器，MVVM这个名字是错误的。

在我看来，MVVMC是正确的名字。

正如你所看到的，ViewModel只是MVC模式的一个附加。它将转换逻辑(例如将对象转换为字符串)从控制器移动到ViewModel。