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

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

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

Ответов (24)

Решение

Model-View-Presenter

In MVP, the Presenter contains the UI business logic for the View. All invocations from the View delegate directly to the Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. One common attribute of MVP is that there has to be a lot of two-way dispatching. For example, when someone clicks the "Save" button, the event handler delegates to the Presenter's "OnSave" method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed.

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

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

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

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

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

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

Модель-Представление-Контроллер

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

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

One other big difference about MVC is that the View does not directly bind to the Model. The view simply renders and is completely stateless. In implementations of MVC, the View usually will not have any logic in the code behind. This is contrary to MVP where it is absolutely necessary because, if the View does not delegate to the Presenter, it will never get called.

Presentation Model

One other pattern to look at is the Presentation Model pattern. In this pattern, there is no Presenter. Instead, the View binds directly to a Presentation Model. The Presentation Model is a Model crafted specifically for the View. This means this Model can expose properties that one would never put on a domain model as it would be a violation of separation-of-concerns. In this case, the Presentation Model binds to the domain model and may subscribe to events coming from that Model. The View then subscribes to events coming from the Presentation Model and updates itself accordingly. The Presentation Model can expose commands which the view uses for invoking actions. The advantage of this approach is that you can essentially remove the code-behind altogether as the PM completely encapsulates all of the behavior for the view. This pattern is a very strong candidate for use in WPF applications and is also called Model-View-ViewModel.

There is a MSDN article about the Presentation Model and a section in the Composite Application Guidance for WPF (former Prism) about Separated Presentation Patterns

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

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

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

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

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

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

Так, если, например, модель - это автомобиль, то ведущий - это своего рода автомобильный ведущий, который показывает свойства автомобиля (год, производитель, места и т. Д.). Представлению известно, что текстовое поле под названием «производитель автомобиля» должно отображать свойство presenter Maker.

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

Эта структура привязки, если ее убрать, на самом деле это контроллер :-)

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

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

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

MVP

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

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

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

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

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

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

MVC

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

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

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

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

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

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

Мнение : Кто это? [ MVP | MVC ]

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

Мнение : Ладно, погоди…. [ MVP | MVC ]

( Просмотр вызова Presenter | Контроллера …) [ MVP | MVC ]

View : Эй, ведущий | Контроллер , пользователь только что нажал кнопку поиска, что мне делать? [ 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 ]

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

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

Мнение : Большое спасибо, докладчик [ MVP ]

Представление : Спасибо, "Контроллер" [ MVC ] (Теперь Представление задается вопросом: как мне представить пользователю результаты, которые я получаю от Модели ? Должен ли год производства фильма быть первым или последним ...? быть в вертикальном или горизонтальном списке? ...)

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

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

В нескольких словах,

  • В MVC View имеет часть пользовательского интерфейса, которая вызывает контроллер, который, в свою очередь, вызывает модель, а модель, в свою очередь, запускает события обратно для просмотра.
  • В MVP View содержит пользовательский интерфейс и вызывает презентатора для реализации. Ведущий вызывает представление напрямую для обновления части пользовательского интерфейса. Модель, которая содержит бизнес-логику, вызывается докладчиком и не взаимодействует с представлением. Так что здесь ведущий делает большую часть работы :)

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

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

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

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

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

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

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

Комбинированный узор

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

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

MVC

MVC

MVP

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

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

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

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

Существует много версий MVC, этот ответ касается исходного MVC в Smalltalk. Вкратце, это изображение mvc против mvp

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

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

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

MVC (Контроллер представления модели)

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

MVP (презентация представления модели)

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

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

Модель-Представление-Контроллер

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

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

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

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

Модель-Просмотр-Презентатор

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

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

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

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

Шаблон MVC

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

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

Шаблон MVP

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

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

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

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

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

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

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

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

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

В проектах MVP докладчик получает доступ к модели и взаимодействует с представлением.

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

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

  • MVP = Model-View-Presenter
  • MVC = модель-представление-контроллер

    1. Оба паттерна презентации. Они разделяют зависимости между моделью (например, объекты домена), вашим экраном / веб-страницей (представление) и тем, как должен вести себя ваш пользовательский интерфейс (презентатор / контроллер).
    2. Они довольно похожи по концепции, люди инициализируют Presenter / Controller по-разному, в зависимости от вкуса.
    3. Отличная статья о различиях здесь . Наиболее примечательно то, что в шаблоне MVC модель обновляет представление.

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

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

Шаблон MVP

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

Шаблон MVC

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

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

MVP: вид главный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оба они позволяют TDD и имеют недостатки и недостатки.

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

Вот еще одна ссылка на сообщение в блоге, дающая немного больше информации по этой теме.

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

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

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

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

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

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