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 指南是：

• 视图 显示某种形状的数据 。他们不知道数据来自哪里。
• ViewModel 持有某种形状的数据和命令 ，它们不知道数据或代码来自哪里或如何显示。
• 模型 保存实际数据 （各种上下文、存储或其他方法）
• 控制器监听并发布事件。控制器提供了控制可以查看哪些数据以及在何处查看数据的逻辑。控制器向 ViewModel 提供命令代码，以便 ViewModel 实际上是可重用的。

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

不要假设控制器已被视图模型淘汰。

我已经开始了一个关于这个主题的博客，我会在可以的时候添加（仅在主机丢失时存档）。将
MVCVM 与常见的导航系统结合起来存在问题，因为大多数导航系统只使用视图和虚拟机，但我将在以后的文章中讨论。

使用 MVCVM 模型的另一个好处是， 在应用程序的整个生命周期中，只有控制器对象需要存在于内存中，
并且控制器主要包含代码和很少的状态数据（即很小的内存开销）。与必须保留视图模型的解决方案相比，这使得内存密集型应用程序的内存占用少得多，并且它非常适合某些类型的移动开发（例如，使用
Silverlight/Prism/MEF 的 Windows Mobile）。这当然取决于应用程序的类型，因为您可能仍需要保留偶尔缓存的 VM
以提高响应速度。

注意：这篇文章已被多次编辑，并没有专门针对所提出的狭隘问题，所以我已经更新了第一部分，现在也涵盖了。 以下评论中的大部分讨论仅与 ASP.Net
相关，与更广泛的情况无关。这篇文章旨在涵盖 MVVM 在 Silverlight、WPF 和 ASP.Net 中的更广泛使用，并试图阻止人们用
ViewModels 替换控制器。