当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
以下是表示通信流程的图示
其他回答
我已经使用了MVP和MVC,尽管我们作为开发人员倾向于关注这两种模式的技术差异,但IMHO中MVP的要点与易于采用性比其他任何东西都更相关。
如果我所在的团队已经具备良好的web表单开发风格背景,那么引入MVP比引入MVC要容易得多。我认为MVP在这种情况下是一场快速的胜利。
我的经验告诉我,将团队从web表单转移到MVP,然后从MVP转移到MVC相对容易;从web表单迁移到MVC更加困难。
我在这里留下一个链接,指向我的一个朋友发表的关于MVP和MVC的一系列文章。
http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx
这两种模式都试图分离表示和业务逻辑,将业务逻辑与UI方面分离
在架构上,MVP是基于页面控制器的方法,而MVC是基于前端控制器的方法。这意味着MVP标准的web表单页面生命周期只是通过从代码后面提取业务逻辑来增强的。换句话说,page是为http请求提供服务的页面。换句话说,MVP IMHO是一种网络形式的进化型增强。另一方面,MVC完全改变了游戏,因为在加载页面之前,请求被控制器类拦截,在那里执行业务逻辑,然后在控制器处理刚刚转储到页面的数据的最终结果(“视图”)从这个意义上讲,MVC看起来(至少在我看来)很像MVP的Supervisory Controller风格,它通过路由引擎增强了MVP的功能
这两种方法都支持TDD,并有其优缺点。
关于如何选择其中一个IMHO的决定应该基于在ASP.NET web表单类型的web开发中投入的时间。如果有人认为自己擅长网络形式,我会建议MVP。如果你在页面生命周期等方面感觉不太舒服的话,MVC可能是一种方法。
下面是另一个博客文章链接,提供了关于这个主题的更多细节
http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx
最简单的答案是视图如何与模型交互。在MVP中,视图由演示者更新,演示者充当视图和模型之间的中介。演示者从视图中获取输入,视图从模型中检索数据,然后执行所需的任何业务逻辑,然后更新视图。在MVC中,模型直接更新视图,而不是通过控制器返回。
在MVP中,视图从演示者中提取数据,演示者从模型中提取数据并准备/规范化数据,而在MVC中,控制器通过在视图中推送从模型中获取数据并进行设置。
在MVP中,您可以使用一个视图来处理多种类型的演示者,也可以使用单个演示者来处理不同的多个视图。
MVP通常使用某种绑定框架,例如Microsoft WPF绑定框架或HTML5和Java的各种绑定框架。
在这些框架中,UI/HTML5/XAML知道每个UI元素显示的演示者的属性,因此当您将视图绑定到演示者时,视图会查找财产,并知道如何从中绘制数据,以及当用户在UI中更改值时如何设置这些属性。
因此,例如,如果模型是一辆汽车,那么演示者是某种汽车演示者,向视图公开汽车的财产(年份、制造商、座位等)。视图知道名为“car maker”的文本字段需要显示演示者maker属性。
然后,您可以将许多不同类型的演示者绑定到视图中,所有演示者都必须具有Maker属性-它可以是飞机、火车或其他任何类型的视图,视图都不在乎。视图从演示者(无论是哪一个)获取数据,只要它实现了一个商定的接口。
这个绑定框架,如果你去掉它,它实际上就是控制器:-)
因此,您可以将MVP视为MVC的演变。
MVC很好,但问题是它的控制器通常是每个视图。控制器A知道如何设置视图A的字段。如果现在,您希望视图A显示模型B的数据,您需要控制器A了解模型B,或者需要控制器A接收带有接口的对象,这就像MVP一样,只是没有绑定,或者您需要重写控制器B中的UI设置代码。
结论:MVP和MVC都是UI模式的解耦,但MVP通常使用一个绑定框架,该框架的底层是MVC。THUS MVP的体系结构级别高于MVC,并且是MVC之上的包装模式。
我简短的观点是:MVP适用于大范围,MVC适用于小范围。有了MVC,我有时会觉得V和C可能被看作是一个不可分割的组件的两面,而不是直接绑定到M,当向下扩展到较短的规模时,如UI控件和基本控件时,必然会出现这种情况。在这种粒度级别上,MVP意义不大。相反,当一个人走向更大的规模时,适当的界面变得更重要,同样,明确的职责分配也同样重要,MVP就来了。
另一方面,当平台特性有助于组件之间的某种关系时,例如在web上,MVC的实现似乎比MVP更容易。