协慌网

标准的 “模型视图控制器” 模式与 Microsoft 的模型 / 视图 / ViewModel 模式之间是否存在差异？

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

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

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

对于 Silverlight 和 WPF，MVVM 模式更具有包容性，并且似乎可以替代 MVC（或将软件组织成单独职责的其他模式）。经常出现在这种模式中的一个假设是， ViewModel只是简单地取代了MVC的控制器（好像你只能用VM替换首字母缩略词中的C并且所有都将被原谅）......

该视图模型并不一定取代单独的控制器的需求。

问题是：可以独立测试 *，特别是在需要时可重用，视图模型不知道哪个视图显示它，但更重要的是不知道它的数据来自何处 。

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

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

从我们目前所看到的 ViewModel 模式的主要好处是从 XAML 代码隐藏中删除代码，使 XAML 编辑成为一个更独立的任务 。我们仍然会在需要时创建控制器来控制（无双关语）我们应用程序的整体逻辑。

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

• 视图显示特定形状的数据 。他们不知道数据来自哪里。
• ViewModels 拥有某种形状的数据和命令 ，它们不知道数据或代码的来源或显示方式。
• 模型包含实际数据 （各种上下文，存储或其他方法）
• 控制器监听和发布事件。控制器提供控制所见数据和位置的逻辑。控制器向 ViewModel 提供命令代码，以便 ViewModel 实际上可重用。

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

不要认为控制器已被 View-models 淘汰。

我已经开始了一个关于这个主题的博客，我将尽我所能添加 。将 MVCVM 与通用导航系统相结合存在一些问题，因为大多数导航系统只使用视图和虚拟机，但我将在后面的文章中介绍它。

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

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

我认为理解这些首字母缩略词的最简单方法是暂时忘掉它们。相反，考虑一下它们所源自的软件。它实际上归结为早期网络和桌面之间的差异。

第一个首字母缩写词 MVC 起源于网络。 （是的，它可能曾经存在过，但网络是如何向大量的 Web 开发人员推广的。）想想数据库，HTML 页面和代码。让我们稍微改进一下以获得 MVC：对于 »database«，让我们假设数据库加接口代码。对于 »HTML pages«，我们假设 HTML 模板和模板处理代码。对于 »code inbetween«，让我们假设代码将用户点击映射到可能影响数据库的操作，肯定会导致显示另一个视图。就是这样，至少为了这个比较的目的。

让我们保留这个网络内容的一个特征，不像现在这样，但是十年前它存在，当时 JavaScript 是一个卑微，卑鄙的烦恼，真正的程序员很好地避开了：HTML 页面本质上是愚蠢和被动的。浏览器是瘦客户端，或者如果你愿意的话，是一个糟糕的客户端。浏览器中没有智能。整页重新加载规则。每次都会重新生成 »view«。

让我们记住，这种网络方式虽然风靡一时，但与桌面相比却是非常落后的。如果您愿意，桌面应用程序是胖客户端或富客户端。 （甚至像 Microsoft Word 这样的程序也可以被认为是某种客户端，文档的客户端。）他们是充满智慧的客户，充满了关于他们数据的知识。他们是有状态的。它们缓存了他们在内存中处理的数据。没有这样的废话作为整页重新加载。

这种丰富的桌面方式可能是第二个首字母缩略词起源于 MVVM 的地方。不要被字母所愚弄，因为 C 的遗漏仍然存在。他们需要。什么都没有被删除。我们只添加一件事：有状态，缓存在客户端上的数据（以及处理该数据的智能）。该数据，实际上是客户端上的缓存，现在称为 “ViewModel”。它允许丰富的交互性。就是这样。

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

我们可以看到，使用 Flash，Silverlight，以及 - 最重要的是 - JavaScript，网络已经接受了 MVVM。浏览器不能再被合法地称为瘦客户端。看看他们的可编程性。看看他们的记忆消耗。查看现代网页上的所有 Javascript 交互性。

就个人而言，我发现这个理论和首字母缩略词业务通过查看它在具体现实中所指的内容更容易理解。抽象概念是有用的，特别是在具体问题上展示时，所以理解可能会完整。

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

控制器将替换为ViewModel 。 ViewModel 位于 UI 层下方。 ViewModel 公开视图所需的数据和命令对象。您可以将此视为一个容器对象，该视图用于获取其数据和操作。 ViewModel 从模型中提取数据。

Russel East做了一个博客，详细讨论了为什么 MVVM 与 MVC 不同