mvmc，或者MVC+，对于企业和快速应用程序开发来说似乎是一种可行的方法。虽然将UI与业务和交互逻辑分开很好，但“纯”MVVM模式和大多数可用示例在单一视图上工作得最好。

对您的设计不太确定，但我的大多数应用程序都包含页面和几个(可重用的)视图，因此ViewModels确实需要在某种程度上进行交互。使用页面作为控制器将完全违背MVVM的目的，因此不为底层逻辑使用“VM-C”方法可能会导致..嗯. .随着应用程序的成熟，具有挑战性的构造。即使在VB-6中，我们中的大多数人也可能停止了对Button事件进行业务逻辑编码，并开始将命令“中继”到控制器，对吗?我最近研究了许多关于这个主题的新兴框架;我最喜欢的显然是Magellan(在codeplex)方法。编码快乐!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

据我所知,MVVM映射到MVC的MV——也就是说,在传统的MVC模式V不沟通直接与M .第二版本的MVC,之间有一个直接联系M和诉MVVM似乎把所有任务相关的M和V交流,和夫妻分离它的c .实际上,还有大范围应用程序工作流程(或实现的使用场景)中没有完全占MVVM。这就是控制器的作用。通过从控制器中删除这些较低级别的方面，它们更干净，更容易修改应用程序的使用场景和业务逻辑，也使控制器更具可重用性。

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

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

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

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

在web开发中，MVC是服务器端，MVVM是客户端(浏览器)。

大多数情况下，浏览器中的MVVM使用javascript。mvc有很多服务器端技术。

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

这里有一个关键的部分:

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