Что такое MVP и MVC и в чем разница?

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

  1. Какие проблемы решают эти шаблоны?
  2. Чем они похожи?
  3. Насколько они разные?
5.08.2008 10:06:33
givanse 11.12.2016 16:51:08
IDK, но предположительно для оригинального MVC, он должен был использоваться в малом. Каждая кнопка, метка и т. Д. Имели свой собственный объект вида и контроллера, или, по крайней мере, так утверждает дядя Боб. Я думаю, что он говорил о Smalltalk. Посмотрите его выступления на YouTube, они захватывающие.
still_dreaming_1 3.09.2017 01:19:59
MVP добавляет дополнительный уровень косвенности путем разбиения View-Controller на View и Presenter ...
the_prole 26.01.2018 02:33:20
Основное отличие состоит в том, что в MVC Контроллер не передает никаких данных из Модели в Представление. Он просто уведомляет представление о получении данных от самой модели. Однако в MVP нет связи между представлением и моделью. Сам докладчик получает любые данные, необходимые из модели, и передает их в представление для отображения. Более подробная информация об этом вместе с образцом Android во всех шаблонах архитектуры находится здесь: digigene.com/category/android/android-architecture
Ali Nem 19.03.2018 11:49:00
Их называют архитектурными образцами, а не дизайнерскими . Если вы хотите узнать разницу, проверьте это
Hasan El-Hefnawy 2.06.2019 22:17:14
24 ОТВЕТА
РЕШЕНИЕ

Model-View-Presenter

В MVP Presenter содержит бизнес-логику пользовательского интерфейса для представления. Все вызовы из View делегируются непосредственно в Presenter. Ведущий также отделен непосредственно от представления и общается с ним через интерфейс. Это делается для того, чтобы разрешить насмешку над видом в модульном тесте. Одним из общих атрибутов MVP является то, что должно быть много двусторонней диспетчеризации. Например, когда кто-то нажимает кнопку «Сохранить», обработчик события делегирует методу «OnSave» докладчика. Как только сохранение завершено, докладчик затем перезвонит представлению через его интерфейс, чтобы представление могло отобразить, что сохранение завершено.

MVP имеет тенденцию быть очень естественной моделью для достижения отдельного представления в веб-формах. Причина в том, что представление всегда сначала создается средой выполнения ASP.NET. Вы можете узнать больше об обоих вариантах .

Два основных варианта

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

  • Pro: максимальная тестируемость поверхности; чистое разделение вида и модели
  • Con: больше работы (например, все свойства установщика), так как вы делаете все привязки данных самостоятельно.

Контролирующий контроллер: ведущий обрабатывает жесты пользователя. Представление привязывается к модели напрямую через привязку данных. В этом случае работа докладчика заключается в том, чтобы передать модель представлению, чтобы она могла с ней связываться. Ведущий также будет содержать логику для таких жестов, как нажатие кнопки, навигация и т. Д.

  • Pro: благодаря использованию привязки данных количество кода уменьшается.
  • Против: там меньше тестируемой поверхности (из-за привязки данных), и в представлении меньше инкапсуляции, поскольку он напрямую взаимодействует с моделью.

Model-View-Controller

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

    Действие в представлении
        -> Вызов на контроллер
        -> Логика контроллера
        -> Контроллер возвращает представление.

Еще одно большое отличие от MVC заключается в том, что представление напрямую не связывается с моделью. Представление просто визуализируется и полностью не имеет состояния. В реализациях MVC View обычно не имеет никакой логики в коде позади. Это противоречит MVP, где это абсолютно необходимо, потому что, если View не делегирует Presenter, он никогда не будет вызван.

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

Еще один шаблон, на который стоит обратить внимание - это модель представления.шаблон. В этом шаблоне нет предъявителя. Вместо этого представление напрямую связывается с моделью представления. Модель презентации - это модель, созданная специально для просмотра. Это означает, что эта Модель может раскрывать свойства, которые никогда не наденут на модель предметной области, поскольку это будет нарушением разделения интересов. В этом случае модель представления связывается с моделью предметной области и может подписываться на события, поступающие из этой модели. Затем представление подписывается на события, поступающие из модели презентации, и обновляется соответствующим образом. Модель представления может предоставлять команды, которые представление использует для вызова действий. Преимущество этого подхода состоит в том, что вы можете по существу полностью удалить выделенный код, поскольку PM полностью инкапсулирует все поведение представления.Модель-Вид-ВидМодель .

В MSDN есть статья о модели представления и раздел в Руководстве по составным приложениям для WPF (прежняя призма) об отдельных шаблонах представления.

1984
3.12.2017 23:01:14
Можете ли вы уточнить эту фразу? Это отличается от MVP, где действия направляются через представление к докладчику. В MVC каждое действие в представлении соотносится с вызовом контроллера и действием. Для меня это звучит как одно и то же, но я уверен, что вы описываете что-то другое.
Panzercrisis 19.10.2016 13:24:23
@Panzercrisis Я не уверен, что автор имел в виду именно это, но я думаю, что они пытались сказать. Как и в этом ответе - упоминается stackoverflow.com/a/2068/74556 , в MVC методы контроллера основаны на поведении - другими словами, вы можете отобразить несколько представлений (но одинаковое поведение) на один контроллер. В MVP презентатор связан ближе к представлению и обычно приводит к отображению, которое ближе к взаимно-однозначному, то есть действие представления отображается на соответствующий метод презентатора. Обычно вы бы не отображали действия другого представления в метод другого докладчика (из другого представления).
Dustin Kendall 28.10.2016 17:50:43
Обратите внимание, что MVC часто используется веб-фреймворками, такими как Laravel, когда полученные URL-запросы (возможно, сделанные пользователями) обрабатываются, Controllerа сгенерированный HTML-код Viewотправляется клиенту. Таким образом, Viewчасть является частью серверной части, а пользователь никогда не сможет получить к нему доступ напрямую, и если вы столкнетесь с чем-то противоположным, то посчитайте это MVC-расширением (или даже нарушением). @Panzercrisis, это отличается от MVP(как это используется в AndroidОС), где actions route through the View to the Presenterи пользователь имеет прямой доступ к View.
Top-Master 29.09.2019 11:50:03

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

Существует дискуссия здесь о различиях между MVC против MVP.

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

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

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

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

18
5.08.2008 10:24:58
MVC и MVP - это шаблоны, а не рамки. Если вы честно думаете, что эта тема была о .NET Framework, то это все равно, что услышать «Интернет» и думать, что это IE.
tereško 18.06.2012 17:26:32
Уверен, что вопрос значительно изменился с того момента, когда он был задан в 2008 году. Кроме того, оглядываясь назад на мой ответ (и это было 4 года назад, поэтому у меня не так много контекста, как у вас), я бы сказал, что я начинаю в общем и затем используйте .NET MVC в качестве конкретного примера.
Matt Mitchell 19.06.2012 05:08:20

Некоторое время назад я писал об этом, цитируя превосходный пост Тодда Снайдера о разнице между ними :

Вот ключевые различия между шаблонами:

MVP Pattern

  • Вид более слабо связан с моделью. Докладчик отвечает за привязку модели к представлению.
  • Легче для модульного тестирования, потому что взаимодействие с представлением осуществляется через интерфейс
  • Обычно вид на карту докладчика один к одному. Сложные представления могут иметь несколько докладчиков.

MVC Pattern

  • Контроллер основан на поведении и может быть разделен между представлениями
  • Может быть ответственным за определение того, какой вид отображать

Это лучшее объяснение в Интернете, которое я мог найти.

420
4.05.2015 03:28:06
Я не понимаю, как в представлении можно более или менее тесно связать с моделью, когда в обоих случаях весь смысл состоит в том, чтобы полностью отделить их. Я не имею в виду, что вы сказали что-то не так - просто запутались в том, что вы имеете в виду.
Bill K 5.10.2011 00:25:40
@pst: с MVP это действительно 1 View = 1 Presenter. С MVC Контроллер может управлять несколькими представлениями. Это действительно так. В модели «вкладки» представьте, что каждая вкладка имеет своего собственного Presenter, а не один контроллер для всех вкладок.
Jon Limjap 29.06.2012 09:46:41
Изначально существует два типа контроллеров: тот, который, как вы сказали, является общим для нескольких представлений, и тот, который относится к конкретным представлениям, в основном предназначен для адаптации интерфейса общего контроллера.
Acsor 11.11.2013 14:12:24
@JonLimjap Что значит один взгляд? В контексте программирования на iOS это один экран? Делает ли это контроллер iOS больше похож на MVP, чем MVC? (С другой стороны, вы также можете иметь несколько контроллеров iOS на экран)
huggie 19.03.2014 07:55:12
Хорошо, что схематическая иллюстрация Тодда MVC полностью противоречит идее разделения Представления и Модели. Если вы посмотрите на диаграмму, она говорит, что модель обновляет представление (стрелка из модели в представление). В какой вселенной есть система, где Модель напрямую взаимодействует с Представлением, отделенным ???
Ash 4.06.2017 02:01:35
  • MVP = Model-View-Presenter
  • MVC = Модель-Вид-Контроллер

    1. Оба шаблона представления. Они разделяют зависимости между моделью (например, объектами домена), вашим экраном / веб-страницей (представлением) и поведением вашего пользовательского интерфейса (Presenter / Controller).
    2. Они довольно похожи по концепции, люди инициализируют Presenter / Controller по-разному в зависимости от вкуса.
    3. Отличная статья о различиях здесь . Наиболее примечательным является то, что шаблон MVC имеет модель, обновляющую представление.
35
20.04.2013 09:17:51
Модельное обновление Вью. И это все еще несвязная система?
Ash 5.06.2017 02:33:59

MVP: вид отвечает.

Представление, в большинстве случаев, создает своего предъявителя. Докладчик будет взаимодействовать с моделью и управлять представлением через интерфейс. Представление иногда взаимодействует с докладчиком, как правило, через некоторый интерфейс. Это сводится к реализации; Вы хотите, чтобы представление вызывало методы докладчика, или вы хотите, чтобы представление имело события, которые слушатель прослушивает? Это сводится к следующему: представление знает о ведущем. Вид делегатов на докладчика.

MVC: контроллер отвечает.

Контроллер создается или доступен на основании какого-либо события / запроса. Затем контроллер создает соответствующий вид и взаимодействует с моделью для дальнейшей настройки вида. Это сводится к следующему: контроллер создает и управляет видом; вид подчинен контроллеру. Вид не знает о контроллере.

109
4.05.2015 03:31:41
«Вид не знает о контроллере». Я думаю, что вы имеете в виду, что представление не имеет прямого контакта с моделью?
Lotus Notes 25.03.2010 07:51:20
Вид никогда не должен знать о модели в другом.
Brian Leahy 29.03.2010 19:03:04
@Brian: «В большинстве случаев View создает своего Presenter». , В основном я видел обратное: презентатор запускает как модель, так и вид. Что ж, View также может запускать Presenter, но этот момент на самом деле не самый характерный. Что важнее всего, происходит позже при жизни.
Hibou57 20.02.2013 15:55:38
Возможно, вы захотите отредактировать свой ответ, чтобы объяснить далее: поскольку представление не знает о контроллере, как пользовательские действия, которые выполняются над «визуальными» элементами, которые пользователь видит на экране (т. Е. Представление), передаются в контроллер ...
Ash 5.06.2017 05:21:54

Также стоит помнить, что существуют разные типы MVP. Фаулер разбил схему на две части - пассивное представление и контролирующий контроллер.

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

Ваша реализация может выглядеть примерно так:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Ваш класс Presenter будет говорить с моделью и «сопоставлять» ее с представлением. Этот подход называется «пассивным представлением». Преимущество заключается в том, что представление легко тестировать, и его легче перемещать между платформами пользовательского интерфейса (Web, Windows / XAML и т. Д.). Недостатком является то, что вы не можете использовать такие вещи, как привязка данных (что действительно полезно в таких средах, как WPF и Silverlight ).

Второй вид MVP - Контролирующий Контроллер. В этом случае у вашего View может быть свойство Customer, которое опять-таки связано с виджетами пользовательского интерфейса. Вам не нужно думать о синхронизации и микро-управлении представлением, и Supervising Controller может вмешаться и помочь, когда это необходимо, например, с помощью сложной логики взаимодействия.

Третий «аромат» MVP (или кто-то, возможно, назвал бы это отдельным шаблоном) - это модель представления (или иногда ее называют Model-View-ViewModel). По сравнению с MVP вы «объединяете» M и P в один класс. У вас есть клиентский объект, к которому привязаны ваши виджеты пользовательского интерфейса, но у вас также есть дополнительные специфичные для пользовательского интерфейса поля, такие как «IsButtonEnabled», «IsReadOnly» и т. Д.

Я думаю, что лучший ресурс, который я нашел в архитектуре пользовательского интерфейса, - это серия постов в блоге, сделанных Джереми Миллером на оглавлении «Построй свою собственную серию CAB» . Он рассмотрел все варианты MVP и показал код C # для их реализации.

Я также писал в блоге о модели Model-View-ViewModel в контексте Silverlight на сайте YouCard. Повторное посещение: Реализация шаблона ViewModel .

33
4.05.2015 03:34:56

MVP - это не обязательно сценарий, когда представление является ответственным (см., Например, MVP Taligent).
Я сожалею, что люди все еще проповедуют это как паттерн («Ответственный взгляд»), в отличие от анти-паттерна, поскольку он противоречит «Это просто взгляд» (Прагматичный программист). «Это просто представление» гласит, что окончательное представление, отображаемое для пользователя, является второстепенной задачей приложения. Шаблон MVP от Microsoft значительно затрудняет повторное использование Views и удобно освобождает дизайнера Microsoft от поощрения плохой практики.

Чтобы быть совершенно откровенным, я думаю, что основные проблемы MVC справедливы для любой реализации MVP, и различия почти полностью семантические. Пока вы следите за разделением интересов между представлением (которое отображает данные), контроллером (который инициализирует и контролирует взаимодействие с пользователем) и моделью (базовые данные и / или службы)), вы получаете преимущества MVC. , Если вы добиваетесь преимуществ, то кого действительно волнует, является ли ваш паттерн MVC, MVP или Supervising Controller? Единственный реальный образец остается как MVC, остальные - только различные ароматы этого.

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

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

170
2.04.2020 17:05:29
Я прочитал несколько ответов и блогов о различиях между MVC / MVP / MVVM / etc '. По сути, когда вы приступаете к делу, все равно. Неважно, есть ли у вас интерфейс или нет, и используете ли вы сеттер (или любую другую языковую функцию). Похоже, что разница между этими шаблонами возникла не из концепции, а из-за различий в реализации различных структур.
Michael 7.03.2011 22:36:15
Я бы не назвал MVP анти-паттерном , так как позже в посте «… остальные [включая MVP] просто отличаются друг от друга [MVC] ..», что подразумевает, что если MVP был анти-паттерном, был MVC ... это просто аромат для подхода другой структуры. (Теперь некоторые конкретные реализации MVP могут быть более или менее желательны, чем некоторые конкретные реализации MVC для различных задач ...)
user166390 15.06.2012 19:31:27
@Quibblsome: «Лично я думаю, что MVP был недавно вновь введен в качестве броского термина, чтобы уменьшить количество споров между семантическими фанатиками, которые утверждают, является ли что-то действительно MVC или нет […] Ни одна из этих причин в моих книгах не оправдывает его существование как отдельный шаблон дизайна. » , Это отличается достаточно, чтобы сделать это отличным. В MVP представлением может быть что угодно, выполняющее предопределенный интерфейс (представление в MVP является автономным компонентом). В MVC Контроллер создан для определенного представления (если арность отношений может заставить кого-то почувствовать, что он стоит другого термина).
Hibou57 20.02.2013 15:50:21
@ Hibou57, ничто не мешает MVC ссылаться на представление как на интерфейс или создавать универсальный контроллер для нескольких различных представлений.
Quibblesome 22.02.2013 16:34:06
Сэмюэл, пожалуйста, уточни, о чем ты говоришь. Если вы не рассказываете мне историю команды, которая "изобрела" MVC, то я невероятно сомневаюсь в вашем тексте. Если вы просто говорите о WinForm, то есть другие способы сделать что-то, и я создал проекты WinForm, в которых привязки элементов управления управляются контроллером, а не «отдельными элементами управления».
Quibblesome 7.04.2014 12:44:40

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

Архитектурно, 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

13
22.09.2008 07:07:21

Я использовал как 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

9
2.01.2009 10:35:25

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

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

6
20.02.2013 16:55:37

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

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

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

В этих рамках UI / 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.

8
4.05.2015 03:17:17

Это упрощение многих вариантов этих шаблонов проектирования, но мне нравится думать о различиях между ними.

MVC

MVC

MVP

введите описание изображения здесь

448
6.07.2013 22:18:01
Это отличное изображение схемы, показывающее абстракцию и полную изоляцию любого графического интерфейса пользователя (просмотр материалов) от API докладчика. Один незначительный момент: мастер-докладчик может быть использован там, где есть только один докладчик, а не один на просмотр, но ваша схема является самой чистой. IMO, самое большое различие между MVC / MVP состоит в том, что MVP старается сохранить вид полностью свободным от чего-либо, кроме отображения текущего «состояния просмотра» (данных представления), и в то же время запрещает представлению любые знания объектов Model. Таким образом, интерфейсы, которые должны быть там, вводят это состояние.
user2080225 15.10.2013 03:30:50
Хорошая картинка. Я очень часто использую MVP, поэтому я хотел бы подчеркнуть одно. По моему опыту, докладчики должны часто общаться друг с другом. То же самое верно для моделей (или бизнес-объектов). Из-за этих дополнительных «синих линий» связи, которые были бы на вашем MVP-изображении, отношения «Презентатор-Модель» могут стать довольно запутанными. Поэтому я склонен придерживаться отношения «один-к-одному» между «модель-презентатор» и «один-ко-многим». Да, это требует некоторых дополнительных методов делегирования в Модели, но это уменьшает многие головные боли, если API Модели изменяется или нуждается в рефакторинге.
splungebob 28.02.2014 14:45:43
Пример MVC неверен; между представлениями и контроллерами существует строгое соотношение 1: 1. По определению, контроллер интерпретирует ввод жестов человеком для создания событий для модели и просмотра для одного элемента управления. Проще говоря, MVC был предназначен для использования только с отдельными виджетами. Один виджет, один вид, один элемент управления.
Samuel A. Falvo II 5.04.2014 15:34:06
@ SamuelA.FalvoII не всегда, есть 1: Многие между контроллерами и представлениями в ASP.NET MVC: stackoverflow.com/questions/1673301/…
StuperUser 7.01.2016 17:57:27
@StuperUser - Не уверен, о чем я думал, когда писал это. Вы, конечно, правы, и, оглядываясь назад на то, что я написал, я должен задаться вопросом, имел ли я в виду какой-то другой контекст, который я не смог сформулировать. Спасибо за исправление.
Samuel A. Falvo II 11.01.2016 23:40:31

Вот иллюстрации, которые представляют коммуникационный поток

введите описание изображения здесь

введите описание изображения здесь

257
12.09.2014 20:47:56
У меня есть вопрос относительно диаграммы MVC. Я не получаю часть, где представление выходит для извлечения данных. Я думаю, что контроллер перешлет к представлению с необходимыми данными.
Brian Rizo 12.05.2015 21:07:21
Если пользователь нажимает кнопку, как это не взаимодействует с представлением? Я чувствую, как в MVC, пользователь взаимодействует с представлением больше, чем контроллер
Jonathan 12.08.2015 03:28:10
Я знаю, что это старый ответ - но может ли кто-нибудь ответить на вопрос @JonathanLeaders? Я исходил из фона winforms, если только вы не выполнили какое-то уникальное кодирование, когда вы нажимаете UI / View, вы узнаете об этом щелчке раньше всего. По крайней мере, насколько я знаю?
Rob P. 4.01.2016 14:44:33
@RobP. Я думаю, что такие графики всегда бывают слишком сложными или слишком простыми. Imo поток диаграммы MVP также сохраняется для приложения MVC. Могут быть различия в зависимости от особенностей языка (привязка данных / наблюдатель), но в конце концов идея состоит в том, чтобы отделить представление от данных / логики приложения.
Luca Fülbier 17.01.2016 09:37:06
@JonathanLeaders Люди действительно имеют в виду разные вещи, когда говорят «MVC». Человек, создавший эту диаграмму, вероятно, имел в виду классический Web MVC, где «пользовательский ввод» - это HTTP-запросы, а «представление, возвращаемое пользователю» - визуализированная HTML-страница. Таким образом, любое взаимодействие между пользователем и представлением «не существует» с точки зрения автора классического веб-приложения MVC.
cubuspl42 12.06.2016 14:38:00

Существует много версий MVC, этот ответ о оригинальном MVC в Smalltalk. Короче говоря, это изображение MVC против MVP

Этот доклад droidcon NYC 2017 - Чистый дизайн приложения с помощью компонентов архитектуры разъясняет это

введите описание изображения здесь введите описание изображения здесь

3
14.11.2017 14:06:21
В MVC Модель никогда не вызывается напрямую с точки зрения
rodi 29.10.2015 07:05:36
Это неточный ответ. Не обманывайтесь. как пишет @rodi, между View и Model нет взаимодействия.
Shawn Mehan 18.11.2015 18:35:12
Изображение MVC является неточным или, в лучшем случае, вводящим в заблуждение, не обращайте внимания на этот ответ.
Jay 7.12.2015 15:21:46
@ Jay1b Какой MVC вы считаете «правильным»? Этот ответ о оригинальном MVC. Есть много других MVC (как в iOS), которые были изменены для адаптации к платформе, скажем, какUIKit
onmyway133 14.11.2017 14:08:17
Что означают стрелки?
problemofficer 10.11.2018 16:04:46

введите описание изображения здесь

MVC (модель просмотра контроллера)

Сначала вход направлен на контроллер, а не на вид. Этот ввод может исходить от пользователя, взаимодействующего со страницей, но это также может быть просто ввод определенного URL в браузер. В любом случае, это Контроллер, который связан с некоторыми функциональными возможностями. Между контроллером и представлением существует отношение многие-к-одному. Это связано с тем, что один контроллер может выбирать различные представления для визуализации в зависимости от выполняемой операции. Обратите внимание на одностороннюю стрелку от контроллера к представлению. Это связано с тем, что представление не имеет каких-либо знаний или ссылок на контроллер. Контроллер действительно передает Модель обратно, поэтому существует знание между Представлением и ожидаемой Моделью, передаваемой в него, но не Контроллер, подающий его.

MVP (ведущий модельного представления)

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

Для получения дополнительной ссылки

77
20.12.2015 02:10:22
Но в MVPшаблоне, когда приложение загружается впервые, не отвечает ли докладчик за загрузку первого представления? Как, например, когда мы загружаем приложение facebook, разве докладчик не отвечает за загрузку страницы входа?
viper 11.11.2016 05:18:05
Ссылка от модели для просмотра в MVC? Возможно, вы захотите отредактировать свой ответ, объяснив, как это делает его «разобщенной» системой, учитывая эту ссылку. Подсказка: вам может быть трудно. Кроме того, если вы не думаете, что читатель с радостью согласится с тем, что всю свою жизнь он неправильно вычислял, вы, возможно, захотите уточнить, почему действия сначала проходят через контроллер в MVC, несмотря на то, что пользователь взаимодействует с «визуальными» элементами на экране (т. Е. Вид), а не какой-то абстрактный слой, который стоит за обработкой.
Ash 5.06.2017 02:32:51
Это явно неправильно ... в MVC модель никогда не взаимодействует напрямую с представлением и наоборот. Они даже не знают, что другой существует. Контроллер - это клей, который удерживает их вместе
MegaManX 25.10.2018 12:39:36
Я согласен с Ash и MegaManX. На диаграмме MVC стрелка должна быть из представления, указывающего на модель (или ViewModel, или DTO), а не из модели в представление; потому что модель не знает о представлении, но представление может знать о модели.
Jboy Flaga 10.04.2019 06:45:39

MVP

MVP расшифровывается как Model - View-Presenter. Это произошло в начале 2007 года, когда Microsoft представила Windows-приложения Smart Client.

Докладчик выступает в роли наблюдателя в MVP, который связывает события и бизнес-логику с моделями.

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

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

Плюсы: в представлении есть только пользовательский интерфейс, а не логика. Высокий уровень тестируемости

Минусы: немного сложнее и больше работы при реализации привязки событий

MVC

MVC расшифровывается как Model-View-Controller. Контроллер отвечает за создание моделей и рендеринг представлений с помощью моделей связывания.

Контроллер является инициатором, и он решает, какое представление визуализировать.

Плюсы: акцент на принципе единой ответственности Высокий уровень тестируемости

Минусы: иногда слишком большая рабочая нагрузка для контроллеров, если попытаться отобразить несколько представлений в одном контроллере.

-1
1.04.2020 03:33:03

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

Комбинированная модель

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

25
13.03.2017 05:54:59
Вместо того, чтобы усложнять вещи, вы могли бы ответить на вопрос. Вот почему большинство из нас здесь. Искал сравнение между mvp и mvc и получил перенаправление здесь, и вы говорите о гармонии тех архитектур, которые не связаны с OP.
Farid 18.08.2019 08:10:45

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

2
22.03.2020 08:52:29
Я понизил голос, потому что afaik модель ничего не знает о представлении в MVC и не может обновить его напрямую, как вы пишете.
problemofficer 10.11.2018 15:58:31
Посмотрите на MVC в Википедии, именно так все и работает.
Clive Jefferies 11.11.2018 22:43:28
Нравится ли это читателям или нет, существует множество источников, которые можно найти в Google, утверждая, что в MVC представление подписывается на обновления модели. и в некоторых случаях может даже быть контроллером и, следовательно, вызывать такие обновления. Если вам это не нравится, то пойдите и пожаловайтесь на эти статьи, или приведите, какую «библию» вы считаете единственным законным источником, вместо того, чтобы опровергать ответы, которые просто передают другую информацию, доступную там!
underscore_d 8.12.2018 10:21:12
Формулировка определенно может быть улучшена, но это правда, что представление подписывается на изменения в модели в MVC. Модель не должна знать View в MVC.
devoured elysium 6.01.2019 12:50:19
спасибо .. мне это очень
Dvyn Resh 24.01.2020 15:27:05

Model-View-Controller

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

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

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

введите описание изображения здесь

Model-View-Presenter

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

Если вы хотите увидеть пример с простой реализацией, пожалуйста, проверьте этот пост на GitHub

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

В чем разница между шаблонами MVC и MVP ?

MVC Pattern

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

  • Может быть ответственным за определение того, какой вид отображать (шаблон переднего контроллера)

MVP Pattern

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

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

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

34
13.06.2019 07:38:06
нет, в mvc нет прямой связи между представлением и моделью. ваша диаграмма неверна.
Özgür 1.06.2019 15:21:42

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

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

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

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

3
31.03.2020 20:58:05
Важный момент от дяди Боба: когда MVG изначально был изобретен Трюгве Реенскаугом, MVC предназначался для каждого виджета, а не для всей формы.
Basil Bourque 12.01.2019 00:01:12

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

Пользователь: Нажмите, нажмите ...

Вид : Кто это? [ MVP | MVC ]

Пользователь: Я только что нажал на кнопку поиска ...

Вид : Хорошо, подожди секунду ... [ MVP | MVC ]

( Просмотр вызова ведущего | контроллера ...) [ MVP | MVC ]

Вид : Эй, Ведущий | Контроллер , Пользователь только что нажал на кнопку поиска, что мне делать? [ MVP | MVC ]

Ведущий | Контролер : Привет, вид , есть ли поисковый запрос на этой странице? [ MVP | MVC ]

Вид : Да,… вот оно… «пианино» [ MVP | MVC ]

Докладчик : Спасибо, View ... пока я ищу поисковый запрос по модели , пожалуйста, покажите ему / ей индикатор выполнения [ MVP | MVC ]

( Ведущий | Контроллер вызывает модель …) [ MVP | MVC ]

Ведущий | Контроллер : Эй, модель , у тебя есть совпадение по этому поисковому запросу: «фортепиано» [ MVP | MVC ]

Модель : Эй, ведущий | Контроллер , дай мне проверить… [ MVP | MVC ]

( Модель делает запрос к базе данных фильмов…) [ MVP | MVC ]

( Спустя некоторое время ... )

-------------- Здесь MVP и MVC начинают расходиться ---------------

Модель : Я нашел для вас список, ведущий , вот он в формате JSON «[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993} ] »[ MVP ]

Модель : есть некоторый результат, контроллер . Я создал переменную поля в моем экземпляре и заполнил ее результатом. Это имя "searchResultsList" [ MVC ]

( Ведущий | Контроллер благодарит Модель и возвращается к Представлению ) [ MVP | MVC ]

Ведущий : Спасибо за ожидание View , я нашел для вас список подходящих результатов и упорядочил их в презентабельном формате: ["Piano Teacher 2001", "Piano 1993"]. Пожалуйста, покажите это пользователю в вертикальном списке. Также, пожалуйста, скройте индикатор прогресса сейчас [ MVP ]

Контроллер : Спасибо за ожидание просмотра , я спросил модель о вашем поисковом запросе. Он говорит, что нашел список совпадающих результатов и сохранил их в переменной с именем "searchResultsList" внутри своего экземпляра. Вы можете получить это оттуда. Также, пожалуйста, скройте индикатор прогресса сейчас [ MVC ]

Просмотр : Большое спасибо Ведущий [ MVP ]

Вид : Спасибо «Controller» [ MVC ] (Теперь View спрашивает себя: Как я должен представить результаты , которые я получаю от модели ? Чтобы пользователь должен год производства фильма пришел первый или последний ... Должен ли это? быть в вертикальном или горизонтальном списке? ...)

В случае , если вы заинтересованы, я пишу серию статей , посвященных приложения архитектурных паттернов (MVC, MVP, MVVP, чистая архитектуру, ...) сопровождается Github репо здесь . Несмотря на то, что образец написан для Android, основные принципы могут быть применены к любому носителю.

57
6.04.2018 13:51:19
По сути, вы пытаетесь сказать, что контроллер управляет логикой представления? Таким образом, это делает представление более тупым, представляя, что происходит и как на представлениях?
Radu 28.08.2018 14:37:18
@Radu, нет, это не микроменеджмент, это то, что делает ведущий, делая представление пассивным или немым
Ali Nem 28.08.2018 22:48:04
В правильном MVC представление вызывает функциональность на контроллере и слушает изменения данных в модели. Представление не получает данные от контроллера, и контроллер НЕ должен указывать представлению отображать, например, индикатор загрузки. Правильный MVC позволяет вам заменить часть представления на ту, которая принципиально отличается. Часть представления содержит логику представления, которая включает индикатор загрузки. Представление вызывает инструкции (в контроллере), контроллер изменяет данные в модели, и модель уведомляет своих слушателей об изменениях своих данных, одним из таких слушателей является представление.
Tommy Andersen 22.10.2018 12:50:11

Я думаю, что это изображение Эрвина Вандервалька (и сопровождающая статья ) является лучшим объяснением MVC, MVP и MVVM, их сходства и различий. Статья не отображается в результатах поиска по запросам на «MVC, MVP и MVVM» , потому что название статьи не содержит слова «MVC» и «MVP»; но это лучшее объяснение, я думаю.

изображение, объясняющее MVC, MVP и MVVM - Эрвин Вандервальк

( Статья также соответствует тому, что дядя Боб Мартин сказал в одном из своих выступлений: что MVC изначально был разработан для небольших компонентов пользовательского интерфейса, а не для архитектуры системы)

4
10.05.2019 01:43:07
  • В MVC View имеет часть пользовательского интерфейса, контроллер является посредником между представлением и моделью, а модель содержит бизнес-логику.
  • В MVP View содержит как пользовательский интерфейс, так и реализацию презентатора, поскольку здесь презентатор представляет собой просто интерфейс, а модель - то же самое, то есть содержит бизнес-логику.
1
9.09.2019 19:31:50

Вы забыли про Action-Domain-Responder ( ADR ).

Как объяснено на некоторых графиках выше, существует прямая связь / связь между моделью и представлением в MVC. Действие выполняется на контроллере , который будет выполнять действие на модели . Это действие в модели , будет вызывать реакцию в View . View , постоянно обновляется , когда модель изменяется состояние «s.

Некоторые люди постоянно забывают, что MVC был создан в конце 70 " , и что Интернет был создан только в конце 80" / начале 90 ". Первоначально MVC создавался не для Интернета, а для настольных приложений, где контроллер Модель и Вид будут сосуществовать вместе.

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

Вместо этого взгляните на Action-Domain-Responder . В ADR Контроллер получает действие , которое будет выполнять операцию в модели / домене . Пока что тоже самое. Разница в том, что он затем собирает ответ / данные этой операции и передает их ответчику ( например:)view() для визуализации. Когда новое действие запрашивается в том же компоненте, контроллер вызывается снова, и цикл повторяется. В ADR нет связи между моделью / доменом и представлением ( ответ Reponser ).

Примечание: Википедия утверждает, что « Каждое действие ADR, однако, представлено отдельными классами или замыканиями ». Это не обязательно правда. Несколько действий могут быть в одном контроллере, и шаблон остается тем же.

2
22.10.2019 10:24:50