标准的“模型视图控制器”模式和微软的模型/视图/视图模型模式之间有区别吗?
当前回答
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指南是:
视图显示数据的特定形状。他们不知道数据从何而来。 ViewModels保存着特定形状的数据和命令,它们不知道数据或代码来自哪里,也不知道它是如何显示的。 模型保存实际数据(各种上下文、存储或其他方法) 控制器监听并发布事件。控制器提供了控制在哪里看到什么数据的逻辑。控制器为ViewModel提供命令代码,以便ViewModel实际上是可重用的。
我们还注意到,Sculpture代码生成框架实现了MVVM和类似于Prism的模式,它还大量使用控制器来分离所有用例逻辑。
不要认为控制器已经被视图模型淘汰了。
我已经开始了一个关于这个主题的博客,当我可以的时候,我会添加进去(只有当主机丢失时存档)。将MVCVM与通用导航系统相结合存在一些问题,因为大多数导航系统只使用视图和vm,但我将在后面的文章中讨论这个问题。
使用MVCVM模型的另一个好处是,在应用程序的生命周期中,只有控制器对象需要存在于内存中,并且控制器主要包含代码和少量的状态数据(即很小的内存开销)。与需要保留视图模型的解决方案相比,这大大减少了应用程序的内存密集型,并且非常适合某些类型的移动开发(例如使用Silverlight/Prism/MEF的Windows mobile)。这当然取决于应用程序的类型,因为您可能仍然需要保留偶尔缓存的虚拟机来响应。
注意:这篇文章已经编辑了很多次,并没有特别针对所提出的狭窄问题,所以我更新了第一部分,现在也包括了这个问题。在下面的评论中,大部分讨论只与ASP有关。而不是更广阔的图景。本文旨在介绍MVVM在Silverlight、WPF和ASP中的广泛使用。Net,并试图阻止人们用ViewModels替换控制器。
其他回答
MVVM是表示模型模式的改进(有争议)。我说有争议,因为唯一的区别是WPF如何提供数据绑定和命令处理的能力。
简单的区别:(灵感来自Yaakov的Coursera AngularJS课程)
MVC(模型-视图-控制器)
模型:模型包含数据信息。不调用或使用控制器和视图。包含业务逻辑和表示数据的方法。其中一些数据可能以某种形式显示在视图中。它还可以包含从某些源检索数据的逻辑。 控制器:作为视图和模型之间的连接。视图调用控制器,控制器调用模型。它基本上通知模型和/或视图进行适当的更改。 视图:处理UI部分。与用户交互。
模型视图视图模型
ViewModel:
它是视图状态的表示。 它保存在视图中显示的数据。 响应视图事件,也就是表示逻辑。 为业务逻辑处理调用其他功能。 永远不要直接要求视图显示任何东西。
首先,MVVM是使用XAML处理显示的MVC模式的发展。本文概述了这两者的一些方面。
模型/视图/视图模型架构的主要目的似乎是在数据(“模型”)之上,还有另一层非可视组件(“视图模型”),它将数据的概念更紧密地映射到数据的视图(“视图”)的概念。视图绑定的是ViewModel,而不是直接绑定模型。
一般来说,MVC用于Web开发,MVVM在WPF/Silverlight开发中最受欢迎。 然而,有时web架构可能混合使用MVC和MVVM。
例如:你可能会使用knockout.js,在这种情况下,你的客户端上会有MVVM。 你的MVC的服务器端也可以改变。在复杂的应用程序中,没有人使用纯模型。使用ViewModel作为MVC的“模型”可能有一定的意义,而你真正的模型基本上将是这个VM的一部分。这为您提供了一个额外的抽象层。
在MVVM中,控制器不会被ViewModel取代,因为ViewModel的功能与控制器完全不同。你仍然需要一个控制器,因为如果没有控制器,你的模型、视图模型和视图就做不了什么…在MVVM中你也有一个控制器,MVVM这个名字是错误的。
在我看来,MVVMC是正确的名字。
正如你所看到的,ViewModel只是MVC模式的一个附加。它将转换逻辑(例如将对象转换为字符串)从控制器移动到ViewModel。