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

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

Мне кажется, что Presenter, Presentation Model, ViewModel и Controller - это, по сути, одно и то же понятие.

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

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

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

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

Источник

6 ответов

Решение

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

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

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

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

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

Ведущий в MVP:

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

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

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

PresentationModel в личку:

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

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

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

ViewModel в MVVM:

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

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

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

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

Источник

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

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

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

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

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

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

Источник

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

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

РЕДАКТИРОВАТЬ:

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

Источник

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

Источник

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

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

рефов:

https://developer.android.com/topic/libraries/architecture/lifecycle

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

Источник

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

Источник
Другие вопросы по тегам