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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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