Вопрос: Что такое MVP и MVC и в чем разница?


Если смотреть за пределы РАД (drag-drop и configure) способ создания пользовательских интерфейсов, которые многие инструменты поощряют, вы, вероятно, столкнетесь с тремя шаблонами проектирования, называемыми Model-View-Controller , Model-View-Presenter а также Model-View-ViewModel , Мой вопрос состоит из трех частей:

  1. Какие проблемы затрагивают эти шаблоны?
  2. Как они похожи?
  3. Насколько они разные?

1823


источник


Ответы:


Model-View-Presenter

В MVP , презентатор содержит бизнес-логику пользовательского интерфейса для представления. Все вызовы делегата View непосредственно в Presenter. Презентатор также отделен напрямую от представления и разговаривает с ним через интерфейс. Это должно позволить насмехаться над представлением в модульном тесте. Одним из общих атрибутов MVP является то, что должно быть много двухсторонней диспетчеризации. Например, когда кто-то нажимает кнопку «Сохранить», обработчик события делегирует метод «OnSave». Как только сохранение будет завершено, Presenter затем перезвонит View через его интерфейс, чтобы View мог показать, что сохранение завершено.

MVP имеет тенденцию быть очень естественной моделью для достижения разделенного представления в Web Forms. Причина в том, что представление всегда создается во время исполнения ASP.NET. Ты можешь узнать больше об обоих вариантах ,

Два основных варианта

Пассивный вид: Вид настолько тупой, насколько это возможно, и содержит почти нулевую логику. Ведущий - средний человек, который разговаривает с Видом и Моделью. Вид и модель полностью защищены друг от друга. Модель может создавать события, но Presenter подписывается на них для обновления представления. В пассивном представлении нет прямой привязки данных, вместо этого View предоставляет свойства сеттера, которые Presenter использует для установки данных. Все состояние управляется в презентаторе, а не в представлении.

  • Pro: максимальная тестируемая поверхность; чистое разделение вида и модели
  • Con: больше работы (например, все свойства сеттера), поскольку вы выполняете все привязки данных самостоятельно.

Контролирующий контроллер: Ведущий обрабатывает жесты пользователя. Вид привязывается к модели непосредственно через привязку данных. В этом случае задача Презентатора заключается в том, чтобы передать модель в представление, чтобы она могла привязываться к ней. Презентатор также будет содержать логику для жестов, таких как нажатие кнопки, навигация и т. Д.

  • Pro: при использовании привязки данных количество кода уменьшается.
  • Con: существует менее проверяемая поверхность (из-за привязки данных), и в представлении меньше инкапсуляции, поскольку она напрямую связана с моделью.

Model-View-Controller

в MVC , Контроллер отвечает за определение того, какой вид отображать в ответ на любое действие, в том числе при загрузке приложения. Это отличается от MVP, где действия маршрутизируются через View to Presenter. В MVC каждое действие в представлении коррелирует с вызовом контроллера вместе с действием. В Интернете каждое действие включает вызов URL-адреса, с другой стороны которого отвечает Контроллер. Как только этот контроллер завершит обработку, он вернет правильный вид. Последовательность продолжается таким образом на протяжении всего срока действия приложения:

Действие в представлении
        -> Звонок на контроллер
        -> Логика контроллеров
        -> Контроллер возвращает представление. 

Еще одна большая разница в MVC заключается в том, что представление напрямую не привязывается к модели. Взгляд просто изображается и полностью без гражданства. В реализациях MVC у View обычно не будет никакой логики в коде. Это противоречит MVP, где это абсолютно необходимо, потому что, если View не передает делегату Presenter, он никогда не будет вызван.

Модель представления

Еще один образец, на который Модель представления шаблон. В этом шаблоне нет презентатора. Вместо этого представление связывается непосредственно с моделью презентации. Модель представления - это модель, созданная специально для представления. Это означает, что эта модель может выставлять свойства, которые никогда не были бы применены к модели домена, поскольку это было бы нарушением разделения. В этом случае модель представления привязывается к модели домена и может подписаться на события, исходящие из этой Модели. Затем «Вид» подписывается на события, поступающие из модели презентации, и соответственно обновляет их. Модель представления может выставлять команды, которые использует вид для вызова действий. Преимущество этого подхода заключается в том, что вы можете существенно удалить код-код вообще, поскольку PM полностью инкапсулирует все поведение для представления. Этот шаблон является очень сильным кандидатом для использования в приложениях WPF и также называется Model-View-ViewModel ,

Eсть Статья MSDN о модели представления и раздел в Руководство по композитным приложениям для WPF (бывшая Призма) о Разделенные шаблоны презентаций


1789



Я писал об этом некоторое время назад, цитируя Отличный пост Тодда Снайдера по разнице между двумя :

Вот основные различия между   шаблоны:

Шаблон MVP

  • Вид более слабо связан с моделью. Ведущий   ответственный за привязку модели к   вид.
  • Простота модульного тестирования, поскольку взаимодействие с   интерфейс
  • Обычно просматривайте презентационную карту один к одному. Сложные представления могут иметь   много презентаторов.

Шаблон MVC

  • Контроллер основан на поведении и может использоваться совместно   Просмотры
  • Может нести ответственность за определение вида отображения

Это лучшее объяснение в Интернете, которое я мог найти.


382



Это упрощение многих вариантов этих шаблонов проектирования, но это то, как мне нравится думать о различиях между ними.

MVC

MVC

MVP

enter image description here


362



Вот иллюстрации, которые представляют собой поток связи

enter image description here

enter image description here


202



MVP является не обязательно сценарий, в котором отображается представление (см., например, MVP Taligent).
Мне доставляет сожаление, что люди по-прежнему проповедуют это как образец (вид в целом), а не анти-шаблон, поскольку он противоречит «Это просто взгляд» (прагматический программист). «Это просто представление» указывает, что конечное представление, отображаемое пользователю, является вторичной проблемой приложения. Шаблон MVP от Microsoft делает повторное использование Views намного сложнее и удобно оправдывает дизайнер Microsoft от поощрения плохой практики.

Чтобы быть совершенно откровенным, я думаю, что основные проблемы MVC справедливы для любой реализации MVP, и различия почти полностью семантичны. До тех пор, пока вы будете разделять проблемы между представлением (которое отображает данные), контроллер (который инициализирует и контролирует взаимодействие с пользователем) и модель (базовые данные и / или услуги)), тогда вы получаете преимущества MVC , Если вы получаете преимущества, то кто действительно заботится о том, является ли ваш шаблон MVC, MVP или контролером? Единственный реальный шаблон остается как MVC, остальные - просто разные вкусы.

Рассматривать это очень интересная статья, в которой подробно перечислены некоторые из этих различных реализаций. Вы можете заметить, что все они в основном делают одно и то же, но несколько иначе.

Я лично считаю, что MVP недавно был недавно введен в качестве броского термина для сокращения аргументов между семантическими фанатиками, которые утверждают, действительно ли что-то действительно MVC или нет, или для оправдания инструментов быстрой разработки приложений Microsoft. Ни одна из этих причин в моих книгах не оправдывает его существование как отдельный шаблон дизайна.


147



MVP: the view is in charge.

The view, in most cases, creates its presenter. The presenter will interact with the model and manipulate the view through an interface. The view will sometimes interact with the presenter, usually through some interface. This comes down to implementation; do you want the view to call methods on the presenter or do you want the view to have events the presenter listens to? It boils down to this: The view knows about the presenter. The view delegates to the presenter.

MVC: the controller is in charge.

The controller is created or accessed based on some event/request. The controller then creates the appropriate view and interacts with the model to further configure the view. It boils down to: the controller creates and manages the view; the view is slave to the controller. The view does not know about the controller.


87



enter image description here

MVC (Model View Controller)

The input is directed at the Controller first, not the view. That input might be coming from a user interacting with a page, but it could also be from simply entering a specific url into a browser. In either case, its a Controller that is interfaced with to kick off some functionality. There is a many-to-one relationship between the Controller and the View. That’s because a single controller may select different views to be rendered based on the operation being executed. Note the one way arrow from Controller to View. This is because the View doesn’t have any knowledge of or reference to the controller. The Controller does pass back the Model, so there is knowledge between the View and the expected Model being passed into it, but not the Controller serving it up.

MVP (Model View Presenter)

The input begins with the View, not the Presenter. There is a one-to-one mapping between the View and the associated Presenter. The View holds a reference to the Presenter. The Presenter is also reacting to events being triggered from the View, so its aware of the View its associated with. The Presenter updates the View based on the requested actions it performs on the Model, but the View is not Model aware.

For more Reference


59



  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Both presentation patterns. They separate the dependencies between a Model (think Domain objects), your screen/web page (the View), and how your UI is supposed to behave (Presenter/Controller)
    2. They are fairly similar in concept, folks initialize the Presenter/Controller differently depending on taste.
    3. A great article on the differences is here. Most notable is that MVC pattern has the Model updating the View.

31



Also worth remembering is that there are different types of MVPs as well. Fowler has broken the pattern into two - Passive View and Supervising Controller.

When using Passive View, your View typically implement a fine-grained interface with properties mapping more or less directly to the underlaying UI widget. For instance, you might have a ICustomerView with properties like Name and Address.

Your implementation might look something like this:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Your Presenter class will talk to the model and "map" it to the view. This approach is called the "Passive View". The benefit is that the view is easy to test, and it is easier to move between UI platforms (Web, Windows/XAML, etc.). The disadvantage is that you can't leverage things like databinding (which is really powerful in frameworks like WPF and Silverlight).

The second flavor of MVP is the Supervising Controller. In that case your View might have a property called Customer, which then again is databound to the UI widgets. You don't have to think about synchronizing and micro-manage the view, and the Supervising Controller can step in and help when needed, for instance with compled interaction logic.

The third "flavor" of MVP (or someone would perhaps call it a separate pattern) is the Presentation Model (or sometimes referred to Model-View-ViewModel). Compared to the MVP you "merge" the M and the P into one class. You have your customer object which your UI widgets is data bound to, but you also have additional UI-spesific fields like "IsButtonEnabled", or "IsReadOnly", etc.

I think the best resource I've found to UI architecture is the series of blog posts done by Jeremy Miller over at The Build Your Own CAB Series Table of Contents. He covered all the flavors of MVP and showed C# code to implement them.

I have also blogged about the Model-View-ViewModel pattern in the context of Silverlight over at YouCard Re-visited: Implementing the ViewModel pattern.


31



Both of these frameworks aim to seperate concerns - for instance, interaction with a data source (model), application logic (or turning this data into useful information) (Controller/Presenter) and display code (View). In some cases the model can also be used to turn a data source into a higher level abstraction as well. A good example of this is the MVC Storefront project.

There is a discussion here regarding the differences between MVC vs MVP.

The distinction made is that in an MVC application traditionally has the view and the controller interact with the model, but not with each other.

MVP designs have the Presenter access the model and interact with the view.

Having said that, ASP.NET MVC is by these definitions an MVP framework because the Controller accesses the Model to populate the View which is meant to have no logic (just displays the variables provided by the Controller).

To perhaps get an idea of the ASP.NET MVC distinction from MVP, check out this MIX presentation by Scott Hanselman.


15



Both are patterns trying to separate presentation and business logic, decoupling business logic from UI aspects

Architecturally, MVP is Page Controller based approach where MVC is Front Controller based approach. That means that in MVP standard web form page life cycle is just enhanced by extracting the business logic from code behind. In other words, page is the one servicing http request. In other words, MVP IMHO is web form evolutionary type of enhancement. MVC on other hand changes completely the game because the request gets intercepted by controller class before page is loaded, the business logic is executed there and then at the end result of controller processing the data just dumped to the page ("view") In that sense, MVC looks (at least to me) a lot to Supervising Controller flavor of MVP enhanced with routing engine

Both of them enable TDD and have downsides and upsides.

Decision on how to choose one of them IMHO should be based on how much time one invested in ASP NET web form type of web development. If one would consider himself good in web forms, I would suggest MVP. If one would feel not so comfortable in things such as page life cycle etc MVC could be a way to go here.

Here's yet another blog post link giving a little bit more details on this topic

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx


12



They each addresses different problems and can even be combined together to have something like below

The Combined Pattern

There is also a complete comparison of MVC, MVP and MVVM here


11