当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型(考虑域对象)、屏幕/网页(视图)和用户界面(演示者/控制器)之间的依赖关系分开它们在概念上相当相似,人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。
其他回答
MVP不一定是视图负责的场景(例如,参见Taligent的MVP)。我觉得很不幸的是,人们仍在宣扬这是一种模式(主管视图),而不是一种反模式,因为它与“这只是一种观点”(实用主义程序员)相矛盾。“这只是一个视图”表示,向用户显示的最终视图是应用程序的次要关注点。微软的MVP模式使视图的重用变得更加困难,并方便地为微软的设计师提供了避免不良做法的借口。
坦率地说,我认为MVC的底层关注点对于任何MVP实现都是正确的,它们之间的差异几乎完全是语义上的。只要您遵循视图(显示数据)、控制器(初始化和控制用户交互)和模型(底层数据和/或服务)之间的关注点分离,就可以实现MVC的好处。如果您正在实现这些好处,那么谁会真正关心您的模式是MVC、MVP还是Supervisory Controller?唯一真正的模式仍然是MVC,其余的只是不同的风格。
考虑一下这篇激动人心的文章,它全面列出了许多不同的实现。你可能会注意到,他们基本上都在做相同的事情,但略有不同。
我个人认为MVP是最近才被重新引入的一个吸引人的术语,目的是为了减少语义偏执者之间的争论,他们争论某些东西是否真正是MVC,或者是为了证明微软的快速应用程序开发工具的合理性。在我的书中,这两个原因都不能证明它是一种独立的设计模式。
鲍勃叔叔的这段视频很好,他在最后简要解释了MVC和MVP。
IMO,MVP是MVC的一个改进版本,基本上可以将你要显示的内容(数据)与你要显示(视图)的方式分开。演示者包含了UI的某种业务逻辑,隐式地规定了应该显示哪些数据,并为您提供了一个哑视图模型列表。当显示数据时,只需将视图(可能包含相同的id)插入适配器,并使用这些视图模型设置相关的视图字段,只需引入最少的代码(仅使用setter)。它的主要好处是您可以针对许多/各种视图测试UI业务逻辑,例如在水平列表或垂直列表中显示项目。
在MVC中,我们通过接口(边界)来粘合不同的层。控制器是我们体系结构的一个插件,但它对显示内容没有任何限制。从这个意义上讲,MVP是一种MVC,其概念是视图可以通过适配器插入控制器。
我希望这有助于更好。
MVC(模型视图控制器)
在MVC中,控制器是负责人!控制器根据一些事件/请求触发或访问,然后管理视图。
MVC中的视图实际上是无状态的,控制器负责选择要显示的视图。
例如:当用户单击“Show MyProfile”(显示我的配置文件)按钮时,将触发控制器。它与模型通信以获得适当的数据。然后,它会显示一个类似于配置文件页面的新视图。控制器可以从模型中获取数据并将其直接馈送到视图(如上图所示),或者让视图从模型本身获取数据。
MVP(模型视图演示者)
在MVP中,视图是负责人!每个视图都会调用其演示者或演示者收听的某些事件。
MVP中的视图不实现任何逻辑,演示者负责实现所有逻辑,并使用某种接口与视图进行通信。
例如:当用户单击“保存”按钮时,视图中的事件处理程序将委派给演示者的“OnSave”方法。演示者将执行所需的逻辑,并与模型进行任何所需的通信,然后通过其界面调用视图,以便视图显示保存已完成。
MVC与MVP
MVC并没有让视图负责,视图充当控制器可以管理和指导的从属对象。在MVC中,视图是无状态的,而MVP中的视图是有状态的,可以随时间变化。在MVP中,视图没有逻辑,我们应该尽可能让它们保持沉默。另一方面,MVC中的视图可能有某种逻辑。在MVP中,演示者与视图分离,并通过接口与视图对话。这允许在单元测试中模拟视图。在MVP中,视图与模型完全隔离。然而,在MVC中,视图可以与模型通信,以使其与最新的最新数据。
这两种模式都试图分离表示和业务逻辑,将业务逻辑与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
MVP代表模型-视图-演示者。2007年初,微软推出了Smart Client windows应用程序。
演示者在MVP中充当监督角色,MVP绑定模型中的视图事件和业务逻辑。
视图事件绑定将从视图界面在Presenter中实现。
视图是用户输入的发起者,然后将事件委派给演示者,演示者处理事件绑定并从模型中获取数据。
赞成的意见:视图只有UI,没有任何逻辑高水平的可测试性
欺骗:实现事件绑定时有点复杂,工作量更大
MVC
MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。
控制器是启动器,它决定渲染哪个视图。
赞成的意见:强调单一责任原则高水平的可测试性
欺骗:如果试图在同一控制器中渲染多个视图,有时控制器的工作量太大。