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

StackOverflow https://stackoverflow.com/questions/4581000

Вопрос

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

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

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

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

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

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

Это было полезно?

Решение

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

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

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

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

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

Ведущий в MVP:

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

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

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

PresentationModel в PM:

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

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

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

ViewModel в MVVM:

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

Один Больше статьи - сравнение.

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

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

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

  • Когда вы обрабатываете, нажмите, изменяя активность («навигация»), это проще с доставателем
  • Изменение изменений просмотра в соответствии с обновлением уровня данных (ASYNCH) будет реализовано лучше всего с 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 enter image description here

enter image description here

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top