什么是MVP和MVC,有什么区别? [英] What are MVP and MVC and what is the difference?

查看:29
本文介绍了什么是MVP和MVC,有什么区别?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

超越RAD(拖放和配置)方式构建用户界面时,许多工具鼓励您可能会遇到三种设计模式,称为 模型-视图-控制器模型-视图-PresenterModel-View-ViewModel.我的问题分为三个部分:

  1. 这些模式解决了哪些问题?
  2. 它们有何相似之处?
  3. 它们有何不同?

解决方案

Model-View-Presenter

MVP 中,Presenter 包含视图的 UI 业务逻辑.从 View 委托直接到 Presenter 的所有调用.Presenter 也直接与 View 解耦,并通过接口与它对话.这是为了允许在单元测试中模拟视图.MVP 的一个共同属性是必须有很多双向调度.例如,当有人点击保存"按钮时,按钮,事件处理程序委托给演示者的OnSave".方法.保存完成后,Presenter会通过接口回调View,让View显示保存完成.

MVP 往往是在 WebForms 中实现分离呈现的一种非常自然的模式.原因是视图始终首先由 ASP.NET 运行时创建.您可以找到详细了解这两种变体.

两个主要变体

被动视图:视图尽可能地笨拙,几乎包含零逻辑.演示者是与视图和模型对话的中间人.视图和模型完全相互屏蔽.模型可能会引发事件,但演示者订阅它们以更新视图.在被动视图中,没有直接的数据绑定,相反,视图公开了演示者用来设置数据的设置器属性.所有状态都在 Presenter 而非 View 中管理.

  • Pro:最大可测试性表面;视图和模型的清晰分离
  • 缺点:由于您自己进行所有数据绑定,因此需要做更多工作(例如所有 setter 属性).

监督控制器:Presenter 处理用户手势.View 通过数据绑定直接绑定到 Model.在这种情况下,Presenter 的工作是将 Model 传递给 View,以便它可以绑定到它.Presenter 还将包含手势的逻辑,例如按下按钮、导航等.

  • 优点:通过利用数据绑定减少了代码量.
  • 缺点:可测试的表面较少(因为数据绑定),并且视图中的封装较少,因为它直接与模型对话.

模型-视图-控制器

MVC 中,控制器负责确定显示哪个视图以响应任何操作,包括应用程序加载时间.这与 MVP 不同,在 MVP 中,动作通过 View 路由到 Presenter.在 MVC 中,视图中的每个动作都与对控制器的调用以及动作相关联.在 Web 中,每个操作都涉及对 URL 另一侧的 URL 的调用,该 URL 的另一端有一个响应的控制器.一旦该控制器完成其处理,它将返回正确的视图.在整个应用程序的整个生命周期中,该序列都会以这种方式继续:

<前>视图中的操作-> 调用控制器-> 控制器逻辑-> 控制器返回视图.

关于 MVC 的另一大区别是 View 不直接绑定到 Model.该视图只是呈现并且完全无状态.在 MVC 的实现中,View 在后面的代码中通常不会有任何逻辑.这与绝对必要的 MVP 相反,因为如果 View 不委托给 Presenter,它将永远不会被调用.

演示模型

要查看的另一种模式是演示模型模式.在这种模式中,没有演示者.相反,视图直接绑定到表示模型.Presentation Model 是专门为 View 制作的模型.这意味着该模型可以公开人们永远不会放在域模型上的属性,因为这会违反关注点分离.在这种情况下,展示模型绑定到域模型并且可以订阅来自该模型的事件.View 然后订阅来自 Presentation Model 的事件并相应地更新自身.表示模型可以公开视图用于调用操作的命令.这种方法的优点是您可以从本质上完全删除代码隐藏,因为 PM 完全封装了视图的所有行为.此模式非常适合用于 WPF 应用程序,也称为 Model-View-ViewModel.

有一个 MSDN 文章关于演示模型和一个部分在 WPF 复合应用指南(前 Prism)中关于 分离的表示模式

When looking beyond the RAD (drag-drop and configure) way of building user interfaces that many tools encourage you are likely to come across three design patterns called Model-View-Controller, Model-View-Presenter and Model-View-ViewModel. My question has three parts to it:

  1. What issues do these patterns address?
  2. How are they similar?
  3. How are they different?

解决方案

Model-View-Presenter

In MVP, the Presenter contains the UI business logic for the View. All invocations from the View delegate directly to the Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. One common attribute of MVP is that there has to be a lot of two-way dispatching. For example, when someone clicks the "Save" button, the event handler delegates to the Presenter's "OnSave" method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed.

MVP tends to be a very natural pattern for achieving separated presentation in WebForms. The reason is that the View is always created first by the ASP.NET runtime. You can find out more about both variants.

Two primary variations

Passive View: The View is as dumb as possible and contains almost zero logic. A Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead, the View exposes setter properties that the Presenter uses to set the data. All state is managed in the Presenter and not the View.

  • Pro: maximum testability surface; clean separation of the View and Model
  • Con: more work (for example all the setter properties) as you are doing all the data binding yourself.

Supervising Controller: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case, it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.

  • Pro: by leveraging data binding the amount of code is reduced.
  • Con: there's a less testable surface (because of data binding), and there's less encapsulation in the View since it talks directly to the Model.

Model-View-Controller

In the MVC, the Controller is responsible for determining which View to display in response to any action including when the application loads. This differs from MVP where actions route through the View to the Presenter. In MVC, every action in the View correlates with a call to a Controller along with an action. In the web, each action involves a call to a URL on the other side of which there is a Controller who responds. Once that Controller has completed its processing, it will return the correct View. The sequence continues in that manner throughout the life of the application:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

One other big difference about MVC is that the View does not directly bind to the Model. The view simply renders and is completely stateless. In implementations of MVC, the View usually will not have any logic in the code behind. This is contrary to MVP where it is absolutely necessary because, if the View does not delegate to the Presenter, it will never get called.

Presentation Model

One other pattern to look at is the Presentation Model pattern. In this pattern, there is no Presenter. Instead, the View binds directly to a Presentation Model. The Presentation Model is a Model crafted specifically for the View. This means this Model can expose properties that one would never put on a domain model as it would be a violation of separation-of-concerns. In this case, the Presentation Model binds to the domain model and may subscribe to events coming from that Model. The View then subscribes to events coming from the Presentation Model and updates itself accordingly. The Presentation Model can expose commands which the view uses for invoking actions. The advantage of this approach is that you can essentially remove the code-behind altogether as the PM completely encapsulates all of the behavior for the view. This pattern is a very strong candidate for use in WPF applications and is also called Model-View-ViewModel.

There is a MSDN article about the Presentation Model and a section in the Composite Application Guidance for WPF (former Prism) about Separated Presentation Patterns

这篇关于什么是MVP和MVC,有什么区别?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆