标准的“模型视图控制器”模式和微软的模型/视图/视图模型模式之间有区别吗?
当前回答
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如何提供数据绑定和命令处理的能力。
据我所知,MVVM映射到MVC的MV——也就是说,在传统的MVC模式V不沟通直接与M .第二版本的MVC,之间有一个直接联系M和诉MVVM似乎把所有任务相关的M和V交流,和夫妻分离它的c .实际上,还有大范围应用程序工作流程(或实现的使用场景)中没有完全占MVVM。这就是控制器的作用。通过从控制器中删除这些较低级别的方面,它们更干净,更容易修改应用程序的使用场景和业务逻辑,也使控制器更具可重用性。
除了给出的许多回答之外,我还想从现代客户端web或富web应用程序的角度添加一些额外的观点。
事实上,现在简单的网站和较大的网络应用程序通常是用许多流行的库(如Bootstrap)构建的。Knockout由Steve Sanderson构建,提供了对MVVM模式的支持,该模式模仿了模式中最重要的行为之一:通过视图模型进行数据绑定。只需一点点JavaScript,就可以实现数据和逻辑,然后使用简单的数据绑定HTML属性将其添加到页面元素中,类似于使用Bootstrap的许多特性。这两个库单独提供互动内容;当与路由结合使用时,这种方法可以产生一种简单而强大的方法来构建单页应用程序。
类似地,现代客户端框架(如Angular)遵循MVC模式,但也添加了一个服务。有趣的是,它被吹捧为模型-视图- whatever (MVW)。(参见Stack Overflow上的这篇文章。)
此外,随着渐进式web框架(如Angular 2)的兴起,我们看到了术语的变化,也许还有一种新的架构模式,组件由视图或模板组成,并与服务交互——所有这些都可以包含在模块中;和一系列模块组成的应用程序。
从实用的角度来看,MVC(模型-视图-控制器)是一种模式。然而,当MVC作为ASP.net MVC使用时,当与实体框架(EF)和“强大的工具”相结合时,它是一种非常强大的、部分自动化的方法,用于将数据库、表和列引入web页面,用于完整的CRUD操作或仅用于R(检索或读取)操作。至少在我使用MVVM时,视图模型与依赖于业务对象的模型交互,这些业务对象是“手工制作”的,经过大量的努力,能够获得与EF提供的“开箱即用”一样好的模型是很幸运的。从实用编程的角度来看,MVC似乎是一个不错的选择,因为它提供了许多开箱即用的实用程序,但仍然有可能添加一些花哨的功能。
MVVM将视图模型添加到混合中。这很重要,因为它允许您大量使用WPF的绑定方法,而无需将所有特定于UI的部分放在常规模型中。
我可能是错的,但是我不确定MVVM真的强迫控制器混合。我发现这个概念更符合:http://martinfowler.com/eaaDev/PresentationModel.html。我认为人们选择将其与MVC结合起来,而不是将其内置到模式中。
推荐文章
- 我怎么知道什么时候创建一个接口?
- 在PHP5中创建单例设计模式
- 什么时候我们应该使用观察者和可观察对象?
- 在哪里放置AutoMapper.CreateMaps?
- 使用Enum实现单例(Java)
- 由Jon Skeet撰写的《Singleton》澄清
- 为什么c#不提供c++风格的'friend'关键字?
- Java / Jakarta EE web开发,我从哪里开始,我需要什么技能?
- 我能在视图中得到当前控制器的名称吗?
- 我应该使用什么MVVM框架?
- 什么是包装器类?
- MVC, MVP和MVVM设计模式在编码c#方面有什么不同
- MVVM:从开始到结束的教程?
- 安卓视图模型与视图模型
- 设计模式:工厂vs工厂方法vs抽象工厂