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

Model-View-Presenter

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

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

Две основные вариации

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

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

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

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

Model-View-Controller

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

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

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

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

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

Существует статья MSDN о модели представления и раздел в руководстве по составному применению для WPF (бывшая Призма) о разделенных шаблонах представления

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

MVC

MVP

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

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

Шаблон MVP

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

шаблон MVC

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

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

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

MVP-это не обязательно сценарий, где вид на плату (см. Taligent по MVP например).
Мне очень жаль, что люди все еще проповедуют это как образец (ответственный взгляд), а не как анти-образец, поскольку это противоречит "It's just a view" (прагматический программист). "It's just a view" указывает, что конечное представление, показанное пользователю, является вторичной заботой приложения. Шаблон Microsoft MVP делает повторное использование представлений намного более сложным и удобно оправдывает дизайнера Microsoft от поощрения плохой практики.

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

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

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

MVP: вид является главным.

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

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

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

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

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

MVP (Модель-Представление-Презентатор)

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

Для получения дополнительной информации

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

Пользователей: Нажмите кнопку …

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

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

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

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

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

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

Вид: Да, ... вот он ... “piano” [ MVP | MVC ]

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

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

Ведущий / контроллер: Эй, модель, у вас есть какие-нибудь совпадения для этого поискового термина?: “piano” [ MVP | MVC ]

Модель: Эй, ведущий / контроллер, позвольте мне проверить ... [ MVP | MVC ]

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

( Через некоторое время ... )

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

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

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

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

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

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

Вид: большое спасибо ведущему [ MVP ]

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

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

• MVP = Model-View-Presenter

• MVC = Model-View-Controller

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

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

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

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

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

Ваш класс Presenter будет разговаривать с моделью и "map" - с представлением. Такой подход называется "Passive View". Преимущество заключается в том, что вид легко тестируется, и его легче перемещать между платформами UI (Web, Windows/XAML, и т. д.). Недостатком является то, что вы не можете использовать такие вещи, как привязка данных (которая действительно мощна в таких фреймворках, как WPF и Silverlight ).

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

Третий "flavor" из MVP (или кто-то, возможно, назвал бы его отдельным шаблоном) - это модель представления (или иногда упоминается Model-View-ViewModel). По сравнению с MVP вы "merge" м и Р в один класс. У вас есть объект customer, к которому привязаны ваши виджеты UI, но у вас также есть дополнительные поля UI-spesific, такие как "IsButtonEnabled", или "IsReadOnly" и т. д.

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

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

Model-View-Controller

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

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

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

Model-View-Presenter

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

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

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

В чем разница между паттернами MVC и MVP ?

шаблон MVC

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

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

Шаблон MVP

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

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

• Как правило, целью ведущий карте один в один. Сложные виды могут иметь несколько ведущих.

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

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

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

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

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

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

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

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

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

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

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

Решение о том, как выбрать один из них IMHO, должно основываться на том, сколько времени человек инвестировал в тип веб-разработки ASP NET web form. Если кто-то считает себя хорошим в веб-формах, я бы предложил 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

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

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

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

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

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

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

Этот связующий фреймворк, если его разобрать, на самом деле является контроллером :-)

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

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

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