MVC和MVVM有什么区别？ [英] What is the difference between MVC and MVVM?
问题描述
标准的模型视图控制器模式和Microsoft的Model / View / ViewModel模式之间有区别吗？
MVC / MVVM不是选择。
这两种模式在ASP.Net和Silverlight中以不同的方式出现/ WPF开发。
对于ASP.Net，MVVM用于视图中的双向绑定数据。这通常是客户端实现（例如使用Knockout.js）。另一方面，MVC是在服务器端之间分离问题的一种方法。
对于Silverlight和WPF，MVVM模式更具包容性并且可以出现以替代MVC（或将软件组织成单独职责的其他模式）。经常出现这种情况的一个假设是， ViewModel 只是在 MVC 中替换控制器（就好像您可以用 VM 替换 C 在首字母缩写，所有将被原谅）...
ViewModel不不需要替换单独的控制器。
问题是：独立可测试*，特别是在需要时可重用，视图模型不知道显示哪个视图，但更重要的是，不知道其数据来自哪里。
*注意：实际上，控制器从ViewModel中删除大部分需要单元测试的逻辑。然后，VM将成为一个愚蠢的容器，需要很少（如果有的话）测试。这是一件好事，因为虚拟机只是设计师和编码器之间的桥梁，所以应该保持简单。
即使在MVVM中，控制器通常会包含所有处理逻辑，并决定使用哪些视图模型在哪些视图中显示哪些数据。
从目前为止我们看到的ViewModel模式的主要优点是从XAML代码隐藏中删除代码，使XAML编辑更独立的任务
EM>。我们仍然在需要时创建控制器，以控制（不是双关语）我们的应用程序的整体逻辑。我们遵循的基本MVCVM指南是：
- 视图显示某种形式的数据。他们不知道数据来自哪里。
- ViewModels持有某种形式的数据和命令，他们不知道数据或代码在哪里
- 模型保存实际数据（各种上下文，商店或其他方法）
- 控制器听和发布事件。控制器提供了控制什么数据被看到和哪里的逻辑。控制器向ViewModel提供命令代码，以便ViewModel实际上是可重用的。
我们还注意到雕塑代码框架实现MVVM和类似于Prism的模式，它还广泛使用控制器来分离所有的用例逻辑。 / p>
不要假设控制器已被View模型淘汰。
我已经开始一个关于这个话题的博客，我将会随时添加。将MVCVM与通用导航系统结合在一起是有问题的，因为大多数导航系统只是使用视图和虚拟机，但我将在后面的文章中介绍。
使用MVCVM模型的是，只有控制器对象需要存在于应用程序生命周期的内存中，并且控制器主要包含代码和小状态数据（即微小的内存开销）。这使得内存密集型应用程序比解决方案要少得多，因为这些应用程序必须保留视图模式，并且是某些类型的移动开发（例如使用Silverlight / Prism / MEF的Windows Mobile）的理想选择。这当然取决于应用程序的类型，因为您可能仍然需要保留偶尔的缓存的虚拟机的响应。
注意：此帖子已被编辑大量时间，并没有专门针对这个狭窄的问题，所以我已经更新了第一部分，现在也覆盖了。在下面的评论中，大部分讨论仅涉及ASP.Net，而不是更广泛的图片。这篇文章旨在涵盖在Silverlight，WPF和ASP.Net中更广泛地使用MVVM，并尝试避免人们用ViewModels替换控制器。
Is there a difference between the standard "Model View Controller" pattern and Microsoft's Model/View/ViewModel pattern?
MVC/MVVM is not an either/or choice.
The two patterns crop up, in different ways, in both ASP.Net and Silverlight/WPF development.
For ASP.Net, MVVM is used to two-way bind data within views. This is usually a client-side implementation (e.g. using Knockout.js). MVC on the other hand is a way of separating concerns on the server-side.
For Silverlight and WPF, the MVVM pattern is more encompassing and can appear to act as a replacement for MVC (or other patterns of organising software into separate responsibilities). One assumption, that frequently came out of this pattern, was that the ViewModel simply replaced the controller in MVC (as if you could just substitute VM for C in the acronym and all would be forgiven)...
The ViewModel does not necessarily replace the need for separate Controllers.
The problem is: that to be independently testable*, and especially reusable when needed, a view-model has no idea what view is displaying it, but more importantly no idea where its data is coming from.
*Note: in practice Controllers remove most of the logic, from the ViewModel, that requires unit testing. The VM then becomes a dumb container that requires little, if any, testing. This is a good thing as the VM is just a bridge, between the designer and the coder, so should be kept simple.
Even in MVVM, controllers will typically contain all processing logic and decide what data to display in which views using which view models.
From what we have seen so far the main benefit of the ViewModel pattern to remove code from XAML code-behind to make XAML editing a more independent task. We still create controllers, as and when needed, to control (no pun intended) the overall logic of our applications.
The basic MVCVM guidelines we follow are:
- Views display a certain shape of data. They have no idea where the data comes from.
- ViewModels hold a certain shape of data and commands, they do not know where the data, or code, comes from or how it is displayed.
- Models hold the actual data (various context, store or other methods)
- Controllers listen for, and publish, events. Controllers provide the logic that controls what data is seen and where. Controllers provide the command code to the ViewModel so that the ViewModel is actually reusable.
We also noted that the Sculpture code-gen framework implements MVVM and a pattern similar to Prism AND it also makes extensive use of controllers to separate all use-case logic.
Don't assume controllers are made obsolete by View-models.
I have started a blog on this topic which I will add to as and when I can. There are issues with combining MVCVM with the common navigation systems, as most navigation systems just use Views and VMs, but I will go into that in later articles.
An additional benefit of using an MVCVM model is that only the controller objects need to exist in memory for the life of the application and the controllers contain mainly code and little state data (i.e. tiny memory overhead). This makes for much less memory-intensive apps than solutions where view-models have to be retained and it is ideal for certain types of mobile development (e.g. Windows Mobile using Silverlight/Prism/MEF). This does of course depend on the type of application as you may still need to retain the occasional cached VMs for responsiveness.
Note: This post has been edited numerous times, and did not specifically target the narrow question asked, so I have updated the first part to now cover that too. Much of the discussion, in comments below, relates only to ASP.Net and not the broader picture. This post was intended to cover the broader use of MVVM in Silverlight, WPF and ASP.Net and try avoid people replacing controllers with ViewModels.
这篇关于MVC和MVVM有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
