MVC 和 MVVM 有什么区别？

如何解决MVC 和 MVVM 有什么区别？

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 替换控制器。

解决方法

标准的“模型视图控制器”模式和微软的模型/视图/视图模型模式有区别吗？