Подтвердить что ты не робот

В чем различия между презентатором, моделью представления, ViewModel и контроллером?

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

Мне кажется, что Presenter, Presentation Model, ViewModel и Controller по сути являются одной и той же концепцией.

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

Ведущий в MVP:

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

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

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

PresentationModel в формате PM:

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

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

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

ViewModel в MVVM:

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

EDIT:

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

enter image description here