MVC и MVP
Простой пример. Пользователь заполняет форму регистрации и отправляет на сервер. Сервер проверяет введённые данные, обнаруживает ошибку и отправляет, уже заполненную, форму обратно пользователю.
MVP был придуман немного при других условиях. Когда вы строите приложение на основе компонентного фреймворка. При этом нет необходимости постоянно пересоздавать представление.
Задача MVP — тоже сделать Представления повторно используемыми. Для этого каждый View реализует определённый интерфейс и реализует механизм событий для обратной связи с Presenter'ом.
Для MVC — это там, где Представление обновляется каждый раз по какому-либо событию, а для MVP, когда Представление не нужно каждый раз пересоздавать.
Использование MVC-шаблона хорошо там, где модули относительно независимы друг от друга. Например, они вызываются из главного меню.
Но здесь кроется коварство использования MVC-шаблона. Как показано на изображении ниже, велик соблазн ссылаться напрямую с представления (View) модуля 'A' на контроллер (Controller) модуля 'B', с модуля 'B' на модуль 'C', с модуля 'C' на модуль 'D'.
Как же вернуть былую слабую связанность модулей системы, сохранив описание бизнес процессов внутри неё?
Для этого нужно вынести конфигурацию бизнес процессов из модулей и поместить её отдельно.
Сделать так, чтобы пользователи и все модули общались через один основной контроллер.
При этом контроллер будет руководствоваться конфигурацией, какие модули, в какой последовательности предоставлять пользователю для работы.