Каковы улучшения MVP по сравнению с MVC?

В течение трех дней я читал о шаблонах Model-View-Controller (MVC) и Model-View-Presenter (MVP) . И есть один вопрос, который меня очень беспокоит. Почему разработчики программного обеспечения изобрели MVP, когда уже был MVC?

С какими проблемами они столкнулись, что MVC не решил (или решил плохо), но MVP может решить? Какие проблемы должен решить MVP?

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

В одной из статей, которые я прочитал, было сказано:

Теперь перейдем к Model View Presenter, который был ответом на неадекватность шаблона MVC применительно к современным компонентным графическим пользовательским интерфейсам. В современных системах с графическим интерфейсом сами компоненты GUI обрабатывают вводимые пользователем данные, такие как движения мыши и щелчки, а не некоторый центральный контроллер.

Итак, я не могу понять, но может ли это быть по-другому, чтобы компоненты GUI не обрабатывали пользовательский ввод самостоятельно? И что именно означает "справиться с собой"?

— Виктор
источник

Дубликат stackoverflow.com/questions/2056/...

— qwerty_so

Я думаю, что это просто «Новая одежда Императора», новое модное слово от Mickeysoft.

— qwerty_so

Виктор, у тебя есть конкретный вопрос, кроме "почему существуют две разные модели?" Есть два разных шаблона, потому что они решают одну и ту же проблему двумя разными способами. Если это помогает, Модель и Представление по сути одинаковы в обоих шаблонах. Сосредоточьтесь на различиях между Контроллером и Докладчиком. Вы можете найти больше помощи здесь: linkedin.com/pulse/…

— Роберт Харви

«Я три дня читал о шаблонах MVC и MVP». Хлоп. Я советую вам принять расслабляющую горячую ванну или пропустить камни через пруд с утками или что-то в этом роде. Такое чтение может, в отсутствие какого-либо практического применения, действительно растопить ваш мозг!

— user1172763 14.12.16

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

— Роберт Харви

Ответы:

MVC концептуально элегантен:

пользовательский ввод обрабатывается контроллером
контроллер обновляет модель
модель обновляет вид / пользовательский интерфейс

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

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

Архитектура MVP заменяет контроллер презентатором, который является посредником между представлением и моделью. Это линеаризует систему:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Это имеет следующие преимущества:

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

Но у этого подхода есть и недостатки:

Это требует больше усилий.
Ведущий может легко превратиться в непригодный «класс бога».
Приложение не имеет единой оси MVP, но имеет несколько осей: по одной для каждого экрана / окна / панели в пользовательском интерфейсе. Это может либо упростить вашу архитектуру, либо ужасно усложнить ее.

— Амон
источник

Хороший ответ, но современный MVC обычно не использует (если вообще использует) обработчики событий, за исключением, возможно, локальной проверки формы, и я не считаю эти события частью MVC. Вот почему у нас есть MVP и MVVM. MVC по существу на стороне сервера.

— Роберт Харви

@amon, спасибо за ваш ответ, он многое говорит мне. И вы упоминаете, что наличие нескольких осей в приложении может упростить архитектуру. Я встречал эту идею во многих статьях, и там упоминалось, что это одна из главных причин изобретать MVP, потому что MVC не соответствует сложным требованиям GUI. То есть, какие требования соответствуют MVP, и как это решает эти требования? Извините за столь настойчивый, но я ДЕЙСТВИТЕЛЬНО палочка, чтобы понять это хорошо.

— Виктор

@Victor Нет лучшего шаблона, но компромиссы разные. MVC может соответствовать сложным требованиям. С точки зрения архитектуры, MVP обеспечивает соотношение 1: 1 между представлениями и докладчиками: у каждого представления есть собственный докладчик, каждый докладчик подключен к одному представлению. В MVC существует отношение n: m: одно представление может отправлять пользовательский ввод нескольким различным контроллерам, а один контроллер может получать входные данные от нескольких представлений. Это более гибко, но и более хаотично - в MVC нет четкой «оси».

— Амон

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

— Амон

@RobertHarvey Я бы сказал, что то, что в Интернете называют «MVC», вообще никогда не было «MVC» по первоначальному определению. Тот, кто похитил аббревиатуру, должен ударить по голове за то, что выбрал загруженный термин и запутал всех.

— jpmc26

В MVP ведущий заменяет контроллер MVC. Разница между ними заключается в том, что докладчик напрямую манипулирует представлением. Он разработан для платформ пользовательского интерфейса, которые в основном управляются событиями (например, Windows Forms), без интенсивной поддержки расширенного связывания данных, которое будет соответствовать шаблону MVVM (например, WPF). В противном случае большая часть логики для управления состоянием представления и обновления модели поддержки будет лежать в самом представлении.

— Майкл Браун
источник