当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
MVP不一定是视图负责的场景(例如,参见Taligent的MVP)。我觉得很不幸的是,人们仍在宣扬这是一种模式(主管视图),而不是一种反模式,因为它与“这只是一种观点”(实用主义程序员)相矛盾。“这只是一个视图”表示,向用户显示的最终视图是应用程序的次要关注点。微软的MVP模式使视图的重用变得更加困难,并方便地为微软的设计师提供了避免不良做法的借口。
坦率地说,我认为MVC的底层关注点对于任何MVP实现都是正确的,它们之间的差异几乎完全是语义上的。只要您遵循视图(显示数据)、控制器(初始化和控制用户交互)和模型(底层数据和/或服务)之间的关注点分离,就可以实现MVC的好处。如果您正在实现这些好处,那么谁会真正关心您的模式是MVC、MVP还是Supervisory Controller?唯一真正的模式仍然是MVC,其余的只是不同的风格。
考虑一下这篇激动人心的文章,它全面列出了许多不同的实现。你可能会注意到,他们基本上都在做相同的事情,但略有不同。
我个人认为MVP是最近才被重新引入的一个吸引人的术语,目的是为了减少语义偏执者之间的争论,他们争论某些东西是否真正是MVC,或者是为了证明微软的快速应用程序开发工具的合理性。在我的书中,这两个原因都不能证明它是一种独立的设计模式。
其他回答
表示器
在MVP中,演示者包含视图的UI业务逻辑。视图中的所有调用都直接委派给演示者。演示者也直接与视图分离,并通过接口与视图对话。这是为了允许在单元测试中模拟视图。MVP的一个共同特点是必须有很多双向调度。例如,当有人单击“保存”按钮时,事件处理程序将委托给演示者的“OnSave”方法。保存完成后,演示者将通过其界面调用视图,以便视图显示保存已完成。
MVP往往是在WebForms中实现分离表示的一种非常自然的模式。原因是视图总是首先由ASP.NET运行时创建。您可以了解更多关于这两种变体的信息。
两种主要变化
被动视图:视图尽可能地哑,几乎包含零逻辑。演示者是与视图和模型对话的中间人。视图和模型彼此完全屏蔽。模型可能会引发事件,但演示者会订阅这些事件以更新视图。在被动视图中,没有直接的数据绑定,相反,视图公开了演示者用于设置数据的setter财产。所有状态都在演示者中管理,而不是在视图中管理。
Pro:最大可测试表面;视图和模型的清晰分离缺点:更多的工作(例如所有setter财产),因为您正在自己进行所有数据绑定。
监督控制器:演示者处理用户手势。视图通过数据绑定直接绑定到模型。在这种情况下,演示者的工作是将模型传递给视图,以便它可以绑定到它。演示者还将包含诸如按下按钮、导航等手势的逻辑。
优点:通过利用数据绑定,减少了代码量。缺点:有一个不太可测试的表面(因为数据绑定),并且视图中的封装更少,因为它直接与模型对话。
模型视图控制器
在MVC中,控制器负责确定响应于任何操作(包括应用程序加载时)显示哪个视图。这与MVP不同,MVP将动作通过视图传递到演示者。在MVC中,视图中的每个动作都与对Controller的调用以及动作相关。在网络中,每个动作都涉及到对URL的调用,URL的另一端有一个控制器进行响应。控制器完成处理后,将返回正确的视图。该序列在应用程序的整个生命周期中以这种方式继续:
Action in the View -> Call to Controller -> Controller Logic -> Controller returns the View.
MVC的另一个重要区别是视图不直接绑定到模型。该视图只是呈现,完全无状态。在MVC的实现中,视图通常在代码后面没有任何逻辑。这与MVP相反,MVP是绝对必要的,因为如果视图不委托给演示者,它将永远不会被调用。
演示模型
另一种模式是演示模型模式。在此模式中,没有演示者。相反,视图直接绑定到演示模型。演示模型是专门为视图设计的模型。这意味着该模型可以公开人们永远不会放在域模型上的财产,因为这将违反关注分离。在这种情况下,表示模型绑定到域模型,并可以订阅来自该模型的事件。然后,视图订阅来自演示模型的事件,并相应地更新自己。表示模型可以公开视图用于调用操作的命令。这种方法的优点是,当PM完全封装了视图的所有行为时,您基本上可以完全删除代码。这种模式非常适合在WPF应用程序中使用,也称为模型视图视图模型。
MSDN上有一篇关于演示模型的文章,WPF(前Prism)的复合应用指南中有一节关于分离的演示模式
鲍勃叔叔的这段视频很好,他在最后简要解释了MVC和MVP。
IMO,MVP是MVC的一个改进版本,基本上可以将你要显示的内容(数据)与你要显示(视图)的方式分开。演示者包含了UI的某种业务逻辑,隐式地规定了应该显示哪些数据,并为您提供了一个哑视图模型列表。当显示数据时,只需将视图(可能包含相同的id)插入适配器,并使用这些视图模型设置相关的视图字段,只需引入最少的代码(仅使用setter)。它的主要好处是您可以针对许多/各种视图测试UI业务逻辑,例如在水平列表或垂直列表中显示项目。
在MVC中,我们通过接口(边界)来粘合不同的层。控制器是我们体系结构的一个插件,但它对显示内容没有任何限制。从这个意义上讲,MVP是一种MVC,其概念是视图可以通过适配器插入控制器。
我希望这有助于更好。
这是对这些设计模式的许多变体的过度简化,但这是我喜欢思考两者之间差异的方式。
MVC
MVP
MVP
MVP代表模型-视图-演示者。2007年初,微软推出了Smart Client windows应用程序。
演示者在MVP中充当监督角色,MVP绑定模型中的视图事件和业务逻辑。
视图事件绑定将从视图界面在Presenter中实现。
视图是用户输入的发起者,然后将事件委派给演示者,演示者处理事件绑定并从模型中获取数据。
赞成的意见:视图只有UI,没有任何逻辑高水平的可测试性
欺骗:实现事件绑定时有点复杂,工作量更大
MVC
MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。
控制器是启动器,它决定渲染哪个视图。
赞成的意见:强调单一责任原则高水平的可测试性
欺骗:如果试图在同一控制器中渲染多个视图,有时控制器的工作量太大。