MVC和MVVM有什么区别？

我曾经认为MVC和MVVM是相同的。现在由于Flux的存在，我能够区分它们：

在MVC中，对于应用程序中的每个视图，你都有一个模型和一个控制器，所以我称之为视图、视图模型和视图控制器。这种模式并没有告诉你如何让一个视图与另一个视图进行通信。因此，在不同的框架中，有不同的实现方式。例如，在某些实现中，控制器相互通信，而在其他实现中，有另一个组件来调解它们之间的通信。甚至还有一些实现方式，其中视图模型相互通信，这是违反MVC模式的，因为视图模型只应该被视图控制器访问。

在MVVM中，每个组件也有一个视图模型。这种模式并没有指定视图如何影响视图模型，因此通常大多数框架将控制器的功能包含在视图模型中。然而，MVVM确实告诉你，你的视图模型数据应该来自模型，即整个模型，它不知道或专门针对特定视图。

为了说明区别，我们来看看Flux模式。Flux模式告诉不同视图在应用程序中如何通信。每个视图都监听一个存储器，并使用分发器触发操作。分发器随后告诉所有存储器有关刚刚进行的操作，存储器更新自己。在Flux中，存储器对应于MVVM中的（通用）模型。它不是针对任何特定视图的。因此，通常当人们使用React和Flux时，每个React组件实际上都实现了MVVM模式。当发生动作时，视图模型调用分发器，最终根据存储器中的更改进行更新，即模型。你不能说每个组件都实现了MVC，因为在MVC中只有控制器才能更新视图模型。因此，MVVM可以与Flux一起工作（MVVM处理视图和视图模型之间的通信，而Flux处理不同视图之间的通信），而MVC无法与Flux一起工作，否则会违反一个关键原则。

从实际角度来看，MVC（Model-View-Controller）是一种模式。但当它作为ASP.net MVC使用时，结合Entity Framework（EF）和“power tools”，它是一种非常强大的、部分自动化的方法，用于将数据库、表和列带到网页上，无论是完全的CRUD操作还是仅R（检索或读取）操作。至少在我使用MVVM时，视图模型与依赖于业务对象的模型交互，这些业务对象又是“手工制作”的，经过很多努力，才能得到像EF“开箱即用”一样好的模型。从实际编程角度来看，MVC似乎是一个很好的选择，因为它为我们提供了很多开箱即用的实用程序，但仍然有可能添加更多功能。

MVC在Web开发中是服务端的，而MVVM是客户端（浏览器）的。

通常情况下，浏览器中使用JavaScript进行MVVM开发。而MVC有许多服务端技术可选择使用。

除了之前提到的回答，我想从现代客户端 Web 或富 Web 应用程序的角度，添加一些额外的观点。

事实上，如今简单的网站和大型 Web 应用程序通常使用许多流行的库，例如 Bootstrap。由 Steve Sanderson 构建，Knockout 提供了对 MVVM 模式的支持，该模式模拟了模式中最重要的行为之一：通过视图模型进行数据绑定。借助少量的 JavaScript，可以实现数据和逻辑，然后将其添加到页面元素中，只需使用简单的 data-bind HTML 属性，类似于使用 Bootstrap 的许多功能。这两个库合在一起就可以提供交互式内容；当与路由结合使用时，这种方法可以产生一个简单但强大的构建单页应用程序的方法。

同样地，像Angular这样的现代客户端框架按照惯例遵循MVC模式，但也添加了一个服务。有趣的是，它被吹捧为“模型-视图-任何东西”（MVW）。 （请参见Stack Overflow上的此篇文章。）
此外，随着渐进式Web框架（如Angular 2）的兴起，我们看到术语发生变化，或许出现了一种新的架构模式，其中组件由视图或模板组成，并与服务交互 - 所有这些都可以包含在模块中；一系列模块组成应用程序。