Что такое MVP и MVC и в чем разница? - PullRequest
2010 голосов
/ 05 августа 2008

Если смотреть дальше RAD (перетаскивание и конфигурирование) способа создания пользовательских интерфейсов, который поощряется многими инструментами, вы, вероятно, столкнетесь с тремя шаблонами проектирования, называемыми Model-View-Controller , Model-View-Presenter и Model-View-ViewModel . Мой вопрос состоит из трех частей:

  1. Какие проблемы решают эти шаблоны?
  2. Чем они похожи?
  3. Чем они отличаются?

Ответы [ 22 ]

23 голосов
/ 29 ноября 2017

Model-View-Controller

MVC - это шаблон для архитектуры программного приложения. Он разделяет логику приложения на три отдельные части, способствуя модульности и простоте совместной работы и повторного использования. Это также делает приложения более гибкими и приветливыми к итерациям. Оно разделяет приложение на следующие компоненты:

  • Модели для обработки данных и бизнес-логики
  • Контроллеры для работы с пользовательским интерфейсом и приложением
  • Представления для обработки объектов графического интерфейса пользователя и представления

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

enter image description here

Model-View-Presenter

  • Модель - это данные, которые будут отображаться в представлении (пользовательский интерфейс).
  • Представление - это интерфейс, который отображает данные (модель) и направляет пользовательские команды (события) в Presenter для обработки этих данных. Представление обычно имеет ссылку на своего докладчика.
  • Presenter является «посредником» (воспроизводится контроллером в MVC) и имеет ссылки как на вид, так и на модель. Обратите внимание, что слово «Модель» вводит в заблуждение. Скорее, это должна быть бизнес-логика, которая извлекает или манипулирует моделью . Например: если у вас есть база данных, хранящая пользователя в таблице базы данных, и ваше представление хочет отобразить список пользователей, то у докладчика будет ссылка на бизнес-логику вашей базы данных (например, DAO), откуда докладчик будет запрашивать список пользователей.

Если вы хотите увидеть образец с простой реализацией, пожалуйста, проверьте это github post

Конкретный рабочий процесс запроса и отображения списка пользователей из базы данных может работать следующим образом: enter image description here

В чем разница между MVC и MVP паттернами?

Шаблон MVC

  • Контроллеры основаны на поведении и могут совместно использоваться представлениями

  • Может отвечать за определение вида для отображения (шаблон переднего контроллера)

Шаблон MVP

  • Вид более слабо связан с моделью. Докладчик отвечает за привязку модели к представлению.

  • Легче для модульного тестирования, потому что взаимодействие с представлением осуществляется через интерфейс

  • Обычно вид на карту докладчика один к одному. Сложные представления могут иметь несколько докладчиков.

19 голосов
/ 13 марта 2017

Каждый из них решает разные проблемы и может даже объединяться, чтобы получить что-то вроде ниже

The Combined Pattern

Здесь также полное сравнение MVC, MVP и MVVM здесь

18 голосов
/ 05 августа 2008

Обе эти структуры стремятся разделить проблемы - например, взаимодействие с источником данных (модель), логику приложения (или превращение этих данных в полезную информацию) (контроллер / докладчик) и код отображения (представление). В некоторых случаях модель также может быть использована для превращения источника данных в абстракцию более высокого уровня. Хорошим примером этого является проект MVC Storefront .

Здесь обсуждается относительно различий между MVC и MVP.

Различие сделано в том, что в приложении MVC традиционно имеет вид, и контроллер взаимодействует с моделью, но не друг с другом.

Проекты MVP предоставляют Presenter доступ к модели и взаимодействуют с представлением.

Сказав это, ASP.NET MVC по этим определениям является каркасом MVP, поскольку Контроллер обращается к Модели для заполнения Представления, которое, как предполагается, не имеет логики (просто отображает переменные, предоставленные Контроллером).

Чтобы, возможно, получить представление об отличии ASP.NET MVC от MVP, посмотрите эту презентацию MIX Скотта Хансельмана.

13 голосов
/ 21 сентября 2008

Оба паттерна пытаются отделить представление и бизнес-логику, отделяя бизнес-логику от аспектов пользовательского интерфейса

Архитектурно, MVP - это подход, основанный на контроллере страниц, где MVC - это подход, основанный на фронт-контроллере. Это означает, что в стандартном MVP жизненный цикл страницы веб-формы просто улучшается за счет извлечения бизнес-логики из кода. Другими словами, страница - это тот, который обслуживает http-запрос. Другими словами, MVP IMHO - это веб-форма эволюционного типа улучшения. MVC, с другой стороны, полностью меняет игру, потому что запрос перехватывается классом контроллера перед загрузкой страницы, тут же выполняется бизнес-логика, а затем в конечном результате обработки контроллером данных, только что сброшенных на страницу («представление») В этом смысле MVC (по крайней мере, мне) очень напоминает разновидность MVP в Supervising Controller, улучшенную механизмом маршрутизации

Оба они включают TDD и имеют свои минусы и минусы.

Решение о том, как выбрать один из них, ИМХО, должно основываться на том, сколько времени вы потратили на разработку веб-формы ASP NET. Если бы кто-то считал себя хорошим в веб-формах, я бы предложил MVP. Если бы вы чувствовали себя не очень комфортно в таких вещах, как жизненный цикл страницы и т. Д., MVC мог бы быть здесь.

Вот еще одна ссылка в блоге, дающая чуть больше деталей по этой теме

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

9 голосов
/ 02 января 2009

Я использовал и MVP, и MVC, и хотя мы, как разработчики, склонны концентрироваться на технических различиях обоих шаблонов, точка зрения на MVP в IMHO гораздо больше связана с простотой принятия, чем с чем-либо еще.

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

Мой опыт подсказывает, что перевести команду из веб-форм в MVP, а затем из MVP в MVC относительно легко; переход от веб-форм к MVC более сложен.

Я оставляю здесь ссылку на серию статей, опубликованных моим другом о MVP и MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

7 голосов
/ 08 июня 2013

В MVP представление извлекает данные из презентатора, который рисует и подготавливает / нормализует данные из модели, в то время как в MVC контроллер извлекает данные из модели и устанавливает, нажимая в представлении.

В MVP вы можете иметь один вид, работающий с несколькими типами докладчиков, и один докладчик, работающий с несколькими различными представлениями.

MVP обычно использует какую-то структуру привязки, такую ​​как среда привязки Microsoft WPF или различные рамки привязки для HTML5 и Java.

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

Таким образом, если, например, модель является автомобилем, то презентатор - это своего рода презентатор автомобиля, который отображает свойства автомобиля (год, производитель, количество мест и т. Д.). Представление знает, что текстовое поле с именем 'car maker' должно отображать свойство Presenter Maker.

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

Этот связующий фреймворк, если его урезать, на самом деле это контроллер :-)

Итак, вы можете рассматривать MVP как эволюцию MVC.

MVC великолепен, но проблема в том, что обычно его контроллер на просмотр. Контроллер A знает, как устанавливать поля представления A. Если теперь вы хотите, чтобы представление A отображало данные модели B, вам нужен контроллер A, чтобы узнать модель B, или вам нужен контроллер A, чтобы получить объект с интерфейсом - который похож на MVP только без привязок, или вам нужно переписать код набора пользовательского интерфейса в контроллере B.

Заключение - оба MVP и MVC являются развязкой шаблонов пользовательского интерфейса, но MVP обычно использует структуру привязок, которая находится под MVC. THUS MVP находится на более высоком архитектурном уровне, чем MVC, и шаблон оболочки выше MVC.

6 голосов
/ 20 февраля 2013

Мой скромный краткий обзор: MVP для больших масштабов и MVC для маленьких масштабов. С MVC я иногда чувствую, что V и C можно увидеть с двух сторон одного неделимого компонента, который напрямую связан с M, и одна неизбежно падает на это при переходе к более коротким масштабам, таким как элементы управления пользовательского интерфейса и базовые виджеты. На этом уровне детализации MVP имеет мало смысла. Когда кто-то наоборот идет в более широкие масштабы, правильный интерфейс становится более важным, то же самое с однозначным распределением обязанностей, и тут приходит MVP.

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

2 голосов
/ 26 января 2018

Это это хорошее видео от дяди Боба, где он кратко объясняет MVC и MVP в конце.

IMO, MVP - это улучшенная версия MVC, в которой вы в основном отделяете заботу о том, что вы собираетесь показывать (данные), от того, как вы собираетесь показывать (представление). Presenter включает в себя своего рода бизнес-логику вашего пользовательского интерфейса, неявно навязывает, какие данные должны быть представлены, и предоставляет вам список глупых моделей представления. И когда приходит время показывать данные, вы просто подключаете свое представление (возможно, с теми же идентификаторами) к своему адаптеру и устанавливаете соответствующие поля представления, используя те модели представления с минимальным количеством вводимого кода (просто используя установщики). Основное преимущество заключается в том, что вы можете проверить свою бизнес-логику пользовательского интерфейса на множестве различных представлений, таких как отображение элементов в горизонтальном или вертикальном списке.

В MVC мы говорим через интерфейсы (границы), чтобы склеивать разные слои. Контроллер - это плагин для нашей архитектуры, но он не имеет такого ограничения, чтобы навязывать то, что показывать. В этом смысле MVP является своего рода MVC с концепцией представлений, подключаемых к контроллеру через адаптеры.

Надеюсь, это поможет лучше.

1 голос
/ 16 ноября 2017

Самый простой ответ - как представление взаимодействует с моделью. В MVP представление связано с презентатором, который действует как посредник между представлением и моделью, принимая входные данные из представления, получая данные из модели, затем выполняя бизнес-логику и, наконец, обновляя представление. В MVC модель обновляет представление напрямую, а не обратно через контроллер.

1 голос
/ 09 сентября 2015

Существует много версий MVC, этот ответ о оригинальном MVC в Smalltalk. Короче говоря, это image of mvc vs mvp

Этот доклад droidcon NYC 2017 - Чистый дизайн приложения с компонентами архитектуры уточняет

enter image description here enter image description here

...