В чем разница между Presenter, Presentation Model, ViewModel и Controller?

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

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

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

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

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

Ведущий в MVP:

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

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

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

Модель презентации в PM:

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

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

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

ViewModel в MVVM:

• ViewModel имеет методы, вызываемые (и свойства) представлением, которое является фактическим компонентом, получающим управление при взаимодействии с пользователем. (Разработчик должен написать некоторый (декларативный) код в представлении, чтобы вызвать 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

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

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

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

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

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

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

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

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

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

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

Одно важное различие между MVP и MVVM заключается в том, что VM может использоваться со многими представлениями, MVP обычно является 1-1 между Presenter и View с контрактным интерфейсом, который обеспечивает его методы. Android много сделал для интеграции MVVM с компонентом ViewModel, построенным поверх сохраненного фрагмента. Это предпочтительный шаблон для архитектуры, который хорошо подходит для любого приложения.