当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
我简短的观点是:MVP适用于大范围,MVC适用于小范围。有了MVC,我有时会觉得V和C可能被看作是一个不可分割的组件的两面,而不是直接绑定到M,当向下扩展到较短的规模时,如UI控件和基本控件时,必然会出现这种情况。在这种粒度级别上,MVP意义不大。相反,当一个人走向更大的规模时,适当的界面变得更重要,同样,明确的职责分配也同样重要,MVP就来了。
另一方面,当平台特性有助于组件之间的某种关系时,例如在web上,MVC的实现似乎比MVP更容易。
其他回答
同样值得记住的是,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上下文中的模型-视图-视图-模型模式的博客。
我认为Erwin Vanderwalk的这张图片(以及附带的文章)是对MVC、MVP和MVVM及其相似性和差异的最好解释。这篇文章没有出现在搜索引擎的“MVC、MVP和MVVM”查询结果中,因为文章的标题没有包含“MVC”和“MVP”字样;但我认为这是最好的解释。
(这篇文章也符合鲍勃·马丁大叔在他的一次演讲中所说的:MVC最初是为小型UI组件而设计的,而不是为系统的架构而设计的)
这两种模式都试图分离表示和业务逻辑,将业务逻辑与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
模型视图控制器
MVC是软件应用程序架构的一种模式。它将应用程序逻辑分为三个独立的部分,促进了模块化和易于协作和重用。它还使应用程序更灵活,更易于迭代。它将应用程序分为以下组件:
处理数据和业务逻辑的模型用于处理用户界面和应用程序的控制器用于处理图形用户界面对象和演示的视图
为了更清楚一点,让我们想象一个简单的购物清单应用程序。我们只需要一份本周需要购买的每件商品的名称、数量和价格的清单。下面我们将描述如何使用MVC实现这些功能。
表示器
模型是将在视图(用户界面)中显示的数据。该视图是一个界面,它显示数据(模型)并将用户命令(事件)发送给演示者,以根据该数据进行操作。视图通常引用其演示者。演示者是“中间人”(由MVC中的控制器扮演),并同时引用视图和模型。请注意,“模型”一词具有误导性。它应该是检索或操纵模型的业务逻辑。例如:如果您有一个数据库将User存储在数据库表中,并且您的View希望显示用户列表,那么Presenter将具有对数据库业务逻辑(如DAO)的引用,Presenter将从中查询用户列表。
如果您想查看具有简单实现的示例,请检查此GitHub帖子
从数据库中查询和显示用户列表的具体工作流可以如下所示:
MVC模式和MVP模式有什么区别?
MVC模式
控制器基于行为,可以跨视图共享可以负责确定要显示的视图(前控制器模式)
MVP模式
视图与模型的耦合更加松散。演示者负责将模型绑定到视图。更容易进行单元测试,因为与视图的交互是通过接口进行的通常视图到演示者的映射是一对一。复杂视图可能有多个演示者。
以下是表示通信流程的图示