当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
这两种模式都试图分离表示和业务逻辑,将业务逻辑与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也有不同的类型。福勒将这种模式分为两种:被动视图和监督控制器。
使用被动视图时,视图通常实现一个细粒度的接口,其中财产或多或少直接映射到底层UI小部件。例如,您可能有一个具有诸如Name和Address等财产的ICustomerView。
您的实现可能如下所示:
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Presenter类将与模型对话,并将其“映射”到视图。这种方法被称为“被动视图”。好处是视图易于测试,并且更容易在UI平台(Web、Windows/XML等)之间移动。缺点是无法利用数据绑定(在WPF和Silverlight等框架中,数据绑定功能非常强大)。
MVP的第二个特点是监督控制员。在这种情况下,您的View可能有一个名为Customer的属性,然后该属性再次绑定到UI小部件。您不必考虑同步和微观管理视图,监督控制器可以在需要时介入并提供帮助,例如使用复杂的交互逻辑。
MVP的第三个“味道”(或者有人可能会称之为一个单独的模式)是演示模型(或者有时称为模型-视图-视图模型)。与MVP相比,你将M和P“合并”为一个类。您有UI小部件数据绑定到的客户对象,但也有其他UI特定字段,如“IsButtonEnabled”或“IsReadOnly”等。
我认为我找到的最好的UI架构资源是Jeremy Miller在the Build Your Own CAB系列目录上发表的一系列博客文章。他涵盖了MVP的所有风格,并展示了实现它们的C#代码。
我也在YouCard网站上写过关于Silverlight上下文中的模型-视图-视图-模型模式的博客。
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型(考虑域对象)、屏幕/网页(视图)和用户界面(演示者/控制器)之间的依赖关系分开它们在概念上相当相似,人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。
不久前,我在博客中引用了托德·斯奈德(Todd Snyder)关于两者区别的精彩文章:
以下是模式:MVP模式视图与模型的耦合更加松散。演示者是负责将模型绑定到视图。更容易进行单元测试,因为与视图的交互是通过的接口通常视图到演示者的映射是一对一。复杂视图可能具有多主持人。MVC模式控制器基于行为,可以在意见可以负责确定要显示的视图
这是我能在网上找到的最好的解释。
MVC(模型视图控制器)
输入首先指向控制器,而不是视图。该输入可能来自与页面交互的用户,但也可能来自简单地在浏览器中输入特定的url。在任何一种情况下,它都是一个控制器,与之接口以启动某些功能。控制器和视图之间存在多对一关系。这是因为单个控制器可以基于正在执行的操作选择要渲染的不同视图。注意从控制器到视图的单向箭头。这是因为视图对控制器没有任何了解或参考。控制器确实会传递回模型,因此视图和传递给它的预期模型之间存在知识,而不是提供服务的控制器。
MVP(模型视图演示者)
输入以视图开始,而不是演示者。视图和关联的演示者之间有一对一的映射。视图包含对演示者的引用。演示者也会对从视图触发的事件做出反应,从而了解与其关联的视图。演示者根据对模型执行的请求操作更新视图,但视图不支持模型。
更多参考信息
这两个框架都旨在分离关注点-例如,与数据源(模型)的交互、应用程序逻辑(或将这些数据转换为有用信息)(控制器/演示者)和显示代码(视图)。在某些情况下,模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。
这里讨论了MVC与MVP之间的区别。
所做的区别在于,在MVC应用程序中,视图和控制器传统上与模型交互,而不是彼此交互。
MVP设计让演示者访问模型并与视图交互。
尽管如此,根据这些定义,ASP.NET MVC是MVP框架,因为控制器访问模型以填充视图,这意味着没有逻辑(只显示控制器提供的变量)。
要了解ASP.NET MVC与MVP的区别,请查看Scott Hanselman的MIX演示。