标准的“模型视图控制器”模式和微软的模型/视图/视图模型模式之间有区别吗?
当前回答
对于不太熟悉架构模式主题的人来说,其他答案可能不太容易理解。对应用程序架构不熟悉的人可能想知道它的选择在实践中如何影响她的应用程序,以及在社区中有什么大惊小怪的。
为了更好地解释上述问题,我编写了这个涉及MVVM、MVP和MVC的剧本。故事开始于一个用户点击电影搜索应用程序中的“FIND”按钮…
用户:单击…
观点:那是谁?[MVVM|MVP|MVC]
用户:我只是点击了搜索按钮……
视图:好的,稍等... .(MVVM MVP | | MVC)
(视图调用ViewModel|Presenter|Controller…)
视图:嘿,ViewModel|Presenter|Controller,一个用户刚刚点击了搜索按钮,我该怎么做?(MVVM MVP | | MVC)
ViewModel|Presenter|Controller:嘿View,这个页面上有搜索词吗?(MVVM MVP | | MVC)
查看:是的,…在这里…" piano " [MVVM|MVP|MVC]
这是MVVM和MVP|MVC之间最重要的区别
演示者|控制器:谢谢视图,…同时我正在模型上查找搜索词,请给他/她一个进度条[MVP|MVC]
(演示者|控制器正在调用模型…)
ViewModel:谢谢,我会在模型上查找搜索词,但不会直接更新你。相反,如果有任何结果,我将触发事件来searchResultsListObservable。所以你最好仔细观察一下。(MVVM)
(当在searchResultsListObservable中观察任何触发器时,视图认为它应该向用户显示一些进度条,因为ViewModel不会在那上面与它对话)
——————————————————————————————
ViewModel|演示者|控制器:嘿,模型,你有匹配这个搜索词吗?: " piano " [MVVM|MVP|MVC]
Model: Hey ViewModel|Presenter|Controller, let me check…[MVVM|MVP|MVC]
(模型正在向电影数据库查询…)[MVVM|MVP|MVC]
(过了一会儿……)
————这是MVVM, MVP和MVC————-之间的分歧点
模型:我为你找到了一个列表,ViewModel|Presenter,这里是JSON“[{" name ": "钢琴老师","年份":2001},{" name ": "钢琴","年份":1993}]" [MVVM|MVP]
模型:有一些结果可用,控制器。我已经在我的实例中创建了一个字段变量,并将其填充为结果。它的名字是searchResultsList [MVC]
(演示者|控制器感谢模型并返回视图)[MVP|MVC]
主持人:感谢您的等待,View,我为您找到了匹配结果的列表,并将它们以像样的格式排列:["钢琴老师2001″,"钢琴1993 "]。同时,现在请隐藏进度条[MVP]
控制器:感谢等待视图,我已经询问了模型关于你的搜索查询。它说它已经找到了一个匹配结果列表,并将它们存储在其实例内名为“searchResultsList”的变量中。你可以从那里得到它。同时,现在请隐藏进度条[MVC]
ViewModel: searchResultsListObservable上的任何观察者都将被通知有这样一个像样格式的新列表:[" Piano Teacher 2001″," Piano 1993 "]。
视图:非常感谢主讲人[MVP]
视图:谢谢你“控制器”[MVC](现在视图在问自己:我应该如何将我从模型得到的结果呈现给用户?电影的制作年份是先写还是后写?)
视图:哦,在searchResultsListObservable中有一个新的触发器…,很好,有一个像样的列表,现在我只需要在列表中显示它。有了结果之后,我还应该隐藏进度条。(MVVM)
如果你感兴趣,我在这里写了一系列文章,通过实现一个电影搜索android应用程序来比较MVVM、MVP和MVC。
其他回答
MVVM是表示模型模式的改进(有争议)。我说有争议,因为唯一的区别是WPF如何提供数据绑定和命令处理的能力。
让我惊讶的是,这是一个投票很高的答案,却没有提到MVVM的起源。MVVM是微软社区常用的术语,它起源于Martin Fowler的表示模型。所以要了解这个模式的动机以及与他人的不同之处,首先要阅读关于这个模式的原文。
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替换控制器。
视图模型是用户界面元素的“抽象”模型。它必须允许您以非可视的方式(例如测试)在视图中执行命令和操作。
如果你使用过MVC,你可能有时会发现创建模型对象来反映视图的状态很有用,例如,显示和隐藏一些编辑对话框等。在这种情况下,您使用的是视图模型。
MVVM模式只是将该实践推广到所有UI元素。
而且这不是微软的模式,WPF / Silverlight数据绑定特别适合使用这种模式。但是没有什么能阻止您使用它与java服务器面,例如。
我曾经认为MVC和MVVM是一样的。现在,由于Flux的存在,我可以分辨出其中的区别:
在MVC中,对于你应用中的每个视图,你都有一个模型和一个控制器,我称之为视图,视图模型,视图控制器。该模式并没有告诉您一个视图如何与另一个视图通信。因此,在不同的框架中有不同的实现。例如,在某些实现中,控制器之间相互通信,而在其他实现中,有另一个组件在它们之间进行中介。甚至还有视图模型相互通信的实现,这打破了MVC模式,因为视图模型应该只由视图控制器访问。
在MVVM中,每个组件都有一个视图模型。该模式没有指定视图应该如何影响视图模型,所以通常大多数框架只在视图模型中包含控制器的功能。但是,MVVM确实告诉您,视图模型的数据应该来自模型,这是整个模型,它不知道或自定义特定的视图。
为了说明差异,让我们以Flux模式为例。Flux模式告诉我们应用中的不同视图应该如何通信。每个视图侦听一个存储,并使用分派器触发操作。分派程序依次将刚刚执行的操作告知所有存储,然后存储更新自己。Flux中的存储对应于MVVM中的(通用)模型。它不是针对任何特定视图定制的。所以通常当人们使用React和Flux时,每个React组件实际上都实现了MVVM模式。当一个动作发生时,视图模型调用分派器,最后它根据存储(即模型)中的变化得到更新。你不能说每个组件都实现了MVC,因为在MVC中只有控制器才能更新视图模型。因此MVVM可以和Flux一起工作(MVVM处理视图和视图模型之间的通信,Flux处理不同视图之间的通信),而MVC不能在不破坏关键原则的情况下与Flux一起工作。