Каковы различия между Presenter, Presentation Model, ViewModel и Controller?

Question

Я довольно хорошо представляю, как работает каждый из этих шаблонов, и знаю о некоторых незначительных различиях между ними, но действительно ли они все отличаются друг от друга?

Мне кажется, что докладчикМодель представления, ViewModel и Controller - это одно и то же понятие.

Почему я не могу классифицировать все эти понятия как контроллеры?Я чувствую, что это может сильно упростить всю идею.

Кто-нибудь может дать четкое описание их различий?

Я хочу уточнить, что я понимаю, как работают шаблоны, иреализовано большинство из них в той или иной технологии.Что я действительно ищу, так это чей-то опыт работы с одним из этих шаблонов, и почему они не считают, например, свою ViewModel Контроллером.

Я дам за это очки репутации, но я ищудействительно хороший ответ.

Answer 1

Помимо уже упомянутых отличных прочтений (Фаулер и Миллер) и чтобы ответить на ваш вопрос о различиях между контроллером / докладчиком / ... с точки зрения разработчика :

Контроллер в MVC :

• Контроллер - это фактический компонент, который вызывается в результате взаимодействия с пользователем.(Разработчику не нужно писать код для делегирования вызовов Контроллеру.)

• Контроллер каким-то образом получает текущие значения из View / context / bag / что угодно, но вы бы этого не сказалион взаимодействует с представлением.

• Контроллер в конце решает, какое представление показать пользователю.В этом Контроллер также показывает явное понятие рабочего процесса навигации приложения.

Presenter в MVP :

• Presenter имеет методы, вызываемыеПредставление, которое является фактическим компонентом, получающим управление при взаимодействии с пользователем.(Разработчик должен написать некоторый код в View для вызова Presenter.)

• Presenter каким-то образом получает текущие значения из View или получает их из View по вызову.Presenter вызывает методы представления, чтобы установить его состояние ( заполнить его говорит Джош Смит).Метод View, вызываемый Presenter , может иметь несколько небольших настроек, выполняемых в его теле.

• Presenter явно не отображает понятие рабочего процесса приложения.Обычно считается, что он возвращает управление вызывающему представлению.

PresentationModel в PM :

• PresentationModel имеет методы, вызываемые представлением, которое является фактическим компонентом, принимающим элемент управления привзаимодействие с пользователем.(Разработчик должен написать некоторый код в представлении, чтобы вызвать PresentationModel.)

• PresentationModel имеет гораздо более болтливое взаимодействие с View по сравнению с Presenter.Он также содержит больше логики для того, чтобы выяснить значение всех настроек, применяемых в представлении, и фактически установить их в представлении.(Эти методы View по очереди не имеют почти никакой логики.)

• PresentationModel явно не отображает понятие рабочего процесса приложения.Обычно считается, что он возвращает управление вызывающему представлению.

ViewModel в MVVM :

• ViewModel имеет методы, вызываемые (и свойства установлены) View, который являетсяфактический компонент, получающий управление при взаимодействии с пользователем.(Разработчик должен написать некоторый (декларативный) код в View для вызова ViewModel.)

• ViewModel не имеет явно болтливой связи с View по сравнению с PresentationModel (т.е.Просмотр коллажа много, фреймворк это делает).Но у этого есть много свойств, которые сопоставляют 1 к 1 с настройками Представления.Он по-прежнему содержит ту же логику, чтобы выяснить значение всех этих настроек.

• ViewModel явно не отображает понятие рабочего процесса приложения.Обычно считается, что он возвращает управление вызывающему представлению.

• Как-то копировать то, что говорит Джош Смит (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx): Шаблон MVVM - это особый случай PM, использующий преимущества фреймворка (такого как WPF / SL), чтобы писать меньшекод.

Answer 2

У Мартина Фаулера есть страница, посвященная шаблонам проектирования пользовательского интерфейса, на которой он определяет, а затем рассказывает о MVC, MVP и других шаблонах.

http://martinfowler.com/eaaDev/uiArchs.html

A Контроллер активен в управлении пользовательским интерфейсом. Например, он будет обрабатывать любые события, инициируемые пользовательским интерфейсом, и обрабатывать их соответствующим образом.

A Presenter , с другой стороны, более пассивен и просто отображает данные через пользовательский интерфейс, который обрабатывает свои собственные события и т. Д., Или делегирует их через докладчика службе или команде.

A ViewModel - это конкретный пример Presenter, разработанный для использования с привязкой WPF / Silverlight.

A Модель представления - это модель, которая может быть представлена ​​непосредственно представлением, поэтому, например, если ваши модели реализуют INotifyPropertyChanged для привязки данных, они будут представлять модели представления.

Answer 3

Разница между ними заключается в том, сколько кода находится в представлении. Выбор между ними фактически является выбором технологий для таких приложений, как WFP, WinForms, ASP MVC (2). Основная идея отделения логики от представления одинакова.

Здесь очень хорошая статья обо всех трех.

EDIT:

Одна Еще статья - сравнение.

Answer 4

По моему мнению, нет никаких реальных концептуальных различий между MVP, MVVC, MVC и презентационной моделью. Есть некоторые подробные различия, но, в конце концов, все это можно по-прежнему рассматривать как настройку Model View Controller. Дополнительное именование просто создает путаницу, и я думаю, что было бы лучше принять терминологию, которая учитывает определенную свободу действий при описании контроллера.

Answer 5

По крайней мере, в .Net, MVP используется в качестве шаблона проектирования.Это обычно используется с приложениями Windows Forms или классическим ASP.Net.С MVC и MVVC они обычно используются с ASP MVC, который использует архитектуру, отличную от обычной ASP.Net.

Answer 6

Одно важное различие только между MVP и MVVM заключается в том, что представление не играет активной роли в обновлении среднего уровня и является «тупым» субъектом, поскольку представление должно быть для отображения, а не для поведения.Presenter рекомендуется для представлений, которые являются «сложными», то есть:

• , когда вы обрабатываете щелчок, изменяя активность («навигацию»), это проще с Presenter
• , изменяющим представления в зависимости от данныхобновление слоя (асинхронное) будет лучше всего реализовано с ViewModel

refs:

https://developer.android.com/topic/libraries/architecture/lifecycle#lc-bp

https://android.jlelse.eu/why-to-choose-mvvm-over-mvp-android-architecture-33c0f2de5516