Что такое MVP и MVC и в чем разница?
https://stackoverflow.com/questions/2056
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Когда смотришь за пределы РАД (перетаскивание и настройка) способ создания пользовательских интерфейсов, который поощряют многие инструменты, скорее всего, вы столкнетесь с тремя шаблонами проектирования, называемыми Модель-Представление-Контроллер, Модель-Представление-Презентатор и Модель-Вид-ViewModel.Мой вопрос состоит из трех частей:
- Какие проблемы решают эти шаблоны?
- Чем они похожи?
- Чем они отличаются друг от друга?
Решение
Модель-Представление-Презентатор
В MVP, презентатор содержит бизнес-логику пользовательского интерфейса для Представления.Все вызовы из представления делегируются непосредственно презентатору.Докладчик также отделен непосредственно от представления и взаимодействует с ним через интерфейс.Это делается для того, чтобы разрешить имитацию представления в модульном тестировании.Одним из общих атрибутов MVP является то, что должно быть много двусторонней диспетчеризации.Например, когда кто-то нажимает кнопку "Сохранить", обработчик событий делегирует метод Ведущего "OnSave".Как только сохранение будет завершено, Ведущий вернет представление через свой интерфейс, чтобы представление могло отобразить, что сохранение завершено.
MVP, как правило, является очень естественным шаблоном для достижения раздельного представления в веб-формах.Причина в том, что представление всегда создается сначала средой выполнения ASP.NET.Ты можешь узнайте больше об обоих вариантах.
Две основные вариации
Пассивный Просмотр: Представление настолько тупое, насколько это возможно, и содержит почти нулевую логику.Ведущий - это посредник, который общается с Зрителем и Моделью.Вид и Модель полностью защищены друг от друга.Модель может вызывать события, но Ведущий подписывается на них для обновления представления.В пассивном представлении нет прямой привязки данных, вместо этого представление предоставляет свойства установщика, которые Докладчик использует для установки данных.Все состояния управляются в презентаторе, а не в Представлении.
- Профессиональный:максимальная тестируемая поверхность;четкое разделение вида и модели
- Con:дополнительная работа (например, со всеми свойствами установщика), поскольку вы выполняете всю привязку данных самостоятельно.
Контролирующий контроллер: Ведущий управляет жестами пользователя.Представление привязывается к Модели непосредственно через привязку данных.В этом случае задача Ведущего - передать модель Представлению, чтобы оно могло привязаться к ней.Докладчик также будет содержать логику для жестов, таких как нажатие кнопки, навигация и т.д.
- Профессиональный:за счет использования привязки к данным объем кода сокращается.
- Con:там меньше тестируемой поверхности (из-за привязки данных) и меньше инкапсуляции в Представлении, поскольку оно взаимодействует непосредственно с Моделью.
Модель-Представление-Контроллер
В MVC, Контроллер отвечает за определение того, какое представление отображать в ответ на любое действие, в том числе при загрузке приложения.Это отличается от MVP, где действия направляются через представление к презентатору.В MVC каждое действие в Представлении коррелирует с вызовом контроллера вместе с действием.В Интернете каждое действие включает в себя вызов URL-адреса, на другой стороне которого есть Контроллер, который отвечает.Как только этот контроллер завершит свою обработку, он вернет правильное представление.Эта последовательность продолжается таким образом на протяжении всего срока службы приложения:
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
Еще одно большое отличие MVC заключается в том, что Представление напрямую не привязывается к Модели.Представление просто визуализируется и полностью не имеет состояния.В реализациях MVC представление обычно не будет иметь никакой логики в стоящем за ним коде.Это противоречит MVP, где это абсолютно необходимо, потому что, если представление не делегируется презентатору, оно никогда не будет вызвано.
Модель представления
Еще одна закономерность, на которую следует обратить внимание, - это Модель представления закономерность.В этом шаблоне нет Ведущего.Вместо этого представление привязывается непосредственно к модели представления.Модель представления - это модель, созданная специально для Представления.Это означает, что эта модель может предоставлять свойства, которые никогда не были бы включены в модель предметной области, поскольку это было бы нарушением принципа разделения интересов.В этом случае модель представления привязывается к модели предметной области и может подписываться на события, исходящие из этой Модели.Затем представление подписывается на события, поступающие из модели представления, и соответствующим образом обновляется.Модель представления может предоставлять команды, которые представление использует для вызова действий.Преимущество этого подхода заключается в том, что вы можете по существу полностью удалить код, поскольку PM полностью инкапсулирует все поведение для представления.Этот шаблон является очень сильным кандидатом для использования в приложениях WPF и также называется Модель-Вид-ViewModel.
Существует Статья в MSDN о модели представления и раздел в Руководство по составному применению для WPF (бывшая Prism) о компании Отдельные шаблоны представления
Другие советы
Это чрезмерное упрощение множества вариантов этих шаблонов проектирования, но именно так мне нравится думать о различиях между ними.
MVC
MVP
Некоторое время назад я писал об этом в блоге, цитируя Превосходный пост Тодда Снайдера о разнице между ними:
Вот ключевые различия между шаблонами:
Шаблон MVP
- Представление более слабо связано с моделью.Докладчик отвечает за привязку модели к представлению.
- Модульное тестирование проще, поскольку взаимодействие с представлением осуществляется через интерфейс
- Обычно просмотр для презентатора сопоставляется один к одному.В сложных представлениях может быть несколько ведущих.
Шаблон MVC
- Контроллер на основе поведения и могут быть общими для всех просмотры
- Может отвечать за определение того, какой вид отображать
Это лучшее объяснение в Интернете, которое я смог найти.
Вот иллюстрации, которые представляют коммуникационный поток
MVP - это нет обязательно сценарий, в котором представление является ответственным (см., например, MVP Taligent).
Я нахожу печальным, что люди все еще проповедуют это как шаблон (ответственный взгляд), в отличие от антишаблона, поскольку это противоречит "Это просто взгляд" (прагматичный программист)."Это просто представление" указывает, что окончательное представление, показанное пользователю, является второстепенной задачей приложения.Шаблон MVP Microsoft значительно усложняет повторное использование представлений и удобно оправдывает разработчика Microsoft за то, что он поощряет плохую практику.
Чтобы быть предельно откровенным, я думаю, что основные проблемы MVC справедливы для любой реализации MVP, и различия почти полностью семантические.Пока вы соблюдаете разделение задач между представлением (которое отображает данные), контроллером (который инициализирует и контролирует взаимодействие с пользователем) и моделью (базовые данные и / или сервисы)), вы получаете преимущества MVC.Если вы получаете преимущества, то кого на самом деле волнует, является ли ваш шаблон MVC, MVP или Контролирующим контроллером?Единственный реальный шаблон остается как MVC, остальные - это просто разные его разновидности.
Рассмотреть это очень интересная статья, в которой подробно перечислен ряд этих различных реализаций.Вы можете заметить, что все они в основном делают одно и то же, но немного по-разному.
Лично я считаю, что MVP лишь недавно был вновь введен в качестве броского термина, чтобы либо уменьшить споры между фанатиками семантики, которые спорят, действительно ли что-то является MVC или нет, либо оправдать быстрые инструменты разработки приложений Microsoft.Ни одна из этих причин, приведенных в моих книгах, не оправдывает его существование как отдельного шаблона проектирования.
MVP:за это отвечает вид.
Представление, в большинстве случаев, создает своего презентатора.Докладчик будет взаимодействовать с моделью и манипулировать представлением через интерфейс.Представление иногда взаимодействует с докладчиком, обычно через какой-либо интерфейс.Это сводится к реализации;вы хотите, чтобы представление вызывало методы в презентаторе или вы хотите, чтобы в представлении были события, которые прослушивает презентатор?Все сводится к следующему:Представление знает о представителе.Представление делегируется ведущему.
MVC:ответственным является контроллер.
Контроллер создается или к нему осуществляется доступ на основе некоторого события / запроса.Затем контроллер создает соответствующее представление и взаимодействует с моделью для дальнейшей настройки представления.Все сводится к следующему:контроллер создает представление и управляет им;представление является подчиненным по отношению к контроллеру.Представление не знает о контроллере.
MVC (Контроллер представления модели)
Входные данные в первую очередь направляются на контроллер, а не на представление.Этот ввод может исходить от пользователя, взаимодействующего со страницей, но он также может быть результатом простого ввода определенного URL-адреса в браузере.В любом случае, это контроллер, с которым можно взаимодействовать для запуска некоторой функциональности.Между контроллером и Представлением существует отношение "многие к одному".Это связано с тем, что один контроллер может выбирать различные представления для визуализации в зависимости от выполняемой операции.Обратите внимание на стрелку в одну сторону от контроллера к Просмотру.Это происходит потому, что представление не имеет никаких сведений о контроллере или ссылок на него.Контроллер действительно передает обратно Модель, поэтому между Представлением и ожидаемой Моделью, передаваемой в него, есть информация, но не Контроллер, обслуживающий ее.
MVP (Ведущий представления модели)
Ввод начинается с представления, а не с презентатора.Между представлением и связанным Презентатором существует взаимно однозначное соответствие.Представление содержит ссылку на Докладчика.Ведущий также реагирует на события, запускаемые из Представления, поэтому он осведомлен о представлении, с которым он связан.Докладчик обновляет Представление на основе запрошенных действий, которые он выполняет над Моделью, но представление не зависит от Модели.
Для получения дополнительной информации Ссылка
Есть много ответов на этот вопрос, но я чувствовал, что необходим какой-то действительно простой ответ, четко сравнивающий эти два вопроса.Вот обсуждение, которое я составил, когда пользователь ищет название фильма в приложении MVP и MVC:
Пользователь:Щелчок щелчок …
Вид:Кто это?[MVP|MVC]
Пользователь:Я просто нажал на кнопку поиска …
Вид:Ладно, подожди секунду... .[MVP|MVC]
( Вид вызывая Ведущий|Контроллер … ) [MVP|MVC]
Вид:Эй Ведущий|Контроллер, пользователь только что нажал на кнопку поиска, что мне делать?[MVP|MVC]
Ведущий|Контроллер:Эй Вид, есть ли какой-нибудь поисковый запрос на этой странице?[MVP|MVC]
Вид:Да, ... вот оно... “пианино”. [MVP|MVC]
Ведущий:Спасибо Вид,... тем временем я ищу поисковый запрос на Модель, пожалуйста, покажите ему / ей индикатор выполнения [MVP|MVC]
( Ведущий|Контроллер вызывает Модель … ) [MVP|MVC]
Ведущий|Контроллер:Эй Модель, Есть ли у вас какое-либо соответствие этому поисковому запросу?:“пианино” [MVP|MVC]
Модель:Эй Ведущий|Контроллер, позвольте мне проверить ... [MVP|MVC]
( Модель делает запрос к базе данных фильмов ... ) [MVP|MVC]
( Через некоторое время ...)
-------------- Вот тут MVP и MVC начинают расходиться ---------------
Модель:Я нашел для тебя список, Ведущий, вот оно в JSON “[{"name": "Учитель игры на фортепиано","year": 2001},{"name":"Фортепиано","year": 1993}]” [MVP]
Модель:Есть какой-то доступный результат, Контроллер.Я создал переменную field в своем экземпляре и заполнил ее результатом.Это называется "searchResultsList". [MVC]
(Ведущий|Контроллер Спасибо Модель и возвращается к Вид) [MVP|MVC]
Ведущий:Спасибо, что подождали Вид, Я нашел для вас список совпадающих результатов и оформил их в презентабельном формате:["Учитель игры на фортепиано 2001", "Фортепиано 1993"].Пожалуйста, покажите это пользователю в виде вертикального списка.Также, пожалуйста, спрячьте индикатор выполнения прямо сейчас [MVP]
Контроллер:Спасибо, что подождали Вид, Я уже спрашивал Модель о вашем поисковом запросе.В нем говорится, что он нашел список совпадающих результатов и сохранил их в переменной с именем "searchResultsList" внутри своего экземпляра.Вы можете получить это оттуда.Также, пожалуйста, спрячьте индикатор выполнения прямо сейчас [MVC]
Вид:Большое вам спасибо Ведущий [MVP]
Вид:Спасибо вам, "Контролер" [MVC] (Теперь Вид ставит под сомнение саму себя:Как я должен представить результаты, которые я получаю от Модель для пользователя?Должен ли год выпуска фильма быть первым или последним ...?Должен ли он быть в вертикальном или горизонтальном списке?...)
На случай, если вам интересно, я написал серию статей, посвященных архитектурным шаблонам приложений (MVC, MVP, MVVP, чистая архитектура, ...), сопровождаемых репозиторием на Github здесь.Несмотря на то, что образец написан для Android, лежащие в его основе принципы могут быть применены к любому носителю.
- MVP = Модель-Представление-Презентатор
MVC = Модель-Представление-Контроллер
- Оба шаблона представления.Они разделяют зависимости между моделью (например, объектами домена), вашим экраном / веб-страницей (представлением) и тем, как должен вести себя ваш пользовательский интерфейс (ведущий / контроллер)
- Они довольно похожи по концепции, люди инициализируют Презентатор / Контроллер по-разному, в зависимости от вкуса.
- Отличная статья о различиях есть здесь.Наиболее примечательным является то, что шаблон MVC содержит модель, обновляющую представление.
Также стоит помнить, что существуют также различные типы MVP.Фаулер разбил шаблон на два - Пассивный просмотр и Контролирующий контроллер.
При использовании пассивного представления ваше представление обычно реализует детализированный интерфейс со свойствами, сопоставляемыми более или менее непосредственно нижележащему виджету пользовательского интерфейса.Например, у вас может быть ICustomerView с такими свойствами, как Name и Address.
Ваша реализация может выглядеть примерно так:
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Ваш класс Presenter будет взаимодействовать с моделью и "сопоставлять" ее с представлением.Такой подход называется "Пассивным взглядом".Преимущество заключается в том, что представление легко тестируется, и его легче перемещать между платформами пользовательского интерфейса (Web, Windows / XAML и т.д.).Недостатком является то, что вы не можете использовать такие вещи, как привязка данных (которая в самом деле мощный в таких фреймворках, как WPF и Серебристый Свет).
Вторая особенность MVP - это Контролирующий контроллер.В этом случае ваше представление может иметь свойство с именем Customer, которое затем снова привязывается к данным виджетов пользовательского интерфейса.Вам не нужно думать о синхронизации и микроуправлении представлением, а Контролирующий контроллер может вмешаться и помочь при необходимости, например, с помощью дополненной логики взаимодействия.
Третьей "изюминкой" MVP (или кто-то, возможно, назвал бы это отдельным шаблоном) является модель представления (или иногда называемая Model-View-ViewModel).По сравнению с MVP вы "объединяете" M и P в один класс.У вас есть объект customer, к которому привязаны данные ваших виджетов пользовательского интерфейса, но у вас также есть дополнительные поля, специфичные для пользовательского интерфейса, такие как "IsButtonEnabled" или "IsReadOnly" и т.д.
Я думаю, что лучший ресурс по архитектуре пользовательского интерфейса, который я нашел, - это серия постов в блоге Джереми Миллера по адресу Оглавление серии Build Your Own CAB.Он рассказал обо всех нюансах MVP и показал код на C # для их реализации.
Я также писал в блоге о шаблоне Model-View-ViewModel в контексте Silverlight по адресу YouCard Повторно посетил:Реализация шаблона ViewModel.
Модель-Представление-Контроллер
MVC это шаблон для архитектуры программного приложения.Он разделяет логику приложения на три отдельные части, способствуя модульности и простоте совместной работы и повторного использования.Это также делает приложения более гибкими и готовыми к итерациям.Это разделяет приложение на следующие компоненты:
- Модели для обработки данных и бизнес-логики
- Контроллеры для работы с пользовательским интерфейсом и приложением
- Число просмотров для работы с объектами графического интерфейса пользователя и представления
Чтобы сделать это немного более понятным, давайте представим себе простое приложение для составления списка покупок.Все, что нам нужно, - это список наименований, количества и цены каждого товара, который нам нужно купить на этой неделе.Ниже мы опишем, как мы могли бы реализовать некоторые из этих функций с помощью MVC.
Модель-Представление-Презентатор
- Тот Самый Модель это данные, которые будут отображаться в представлении (пользовательском интерфейсе).
- Тот Самый Вид это интерфейс, который отображает данные (модель) и направляет пользовательские команды (события) Ведущему для воздействия на эти данные.Представление обычно содержит ссылку на своего Презентатора.
- Тот Самый Ведущий является ”посредником" (его играет контроллер в MVC) и имеет ссылки как на view, так и на model. Пожалуйста, обратите внимание, что слово “Модель” вводит в заблуждение.Скорее всего, это должно быть бизнес-логика, которая извлекает модель или манипулирует ею.Например:Если у вас есть база данных, хранящая пользователя в таблице базы данных, и ваше представление хочет отобразить список пользователей, то у Ведущего будет ссылка на бизнес-логику вашей базы данных (например, DAO), откуда Ведущий будет запрашивать список пользователей.
Если вы хотите увидеть образец с простой реализацией, пожалуйста, проверьте это сообщение на github
Конкретный рабочий процесс запроса и отображения списка пользователей из базы данных мог бы работать следующим образом:
Что такое разница между MVC и MVP закономерности?
Шаблон MVC
Контроллеры основаны на поведении и могут быть общими для всех представлений
Может отвечать за определение того, какой вид отображать (шаблон фронтального контроллера).
Шаблон MVP
Представление более слабо связано с моделью.Ведущий отвечает за привязку модели к представлению.
Модульное тестирование проще, потому что взаимодействие с представлением осуществляется через интерфейс
Обычно просмотр для презентатора сопоставляется один к одному.В сложных представлениях может быть несколько ведущих.
Каждый из них решает разные проблемы и даже может быть объединен вместе, чтобы получить что-то вроде приведенного ниже
Существует также полное сравнение MVC, MVP и MVVM приведено здесь
Обе эти платформы направлены на разделение задач - например, взаимодействие с источником данных (моделью), логикой приложения (или превращение этих данных в полезную информацию) (Контроллер / презентатор) и отображаемым кодом (представление).В некоторых случаях модель также может быть использована для превращения источника данных в абстракцию более высокого уровня.Хорошим примером этого является Проект витрины магазина MVC.
Идет дискуссия здесь что касается различий между MVC и MVP.
Различие заключается в том, что в приложении MVC традиционно представление и контроллер взаимодействуют с моделью, но не друг с другом.
В проектах MVP ведущий получает доступ к модели и взаимодействует с представлением.
Сказав это, ASP.NET По этим определениям MVC является фреймворком MVP, потому что контроллер обращается к Модели для заполнения представления, которое не должно иметь логики (просто отображает переменные, предоставляемые контроллером).
Чтобы, возможно, получить представление о ASP.NET отличии MVC от MVP, ознакомьтесь презентация этого МИКСА автор: Скотт Хансельман.
Оба шаблона пытаются разделить презентацию и бизнес-логику, отделяя бизнес-логику от аспектов пользовательского интерфейса
С архитектурной точки зрения MVP - это подход, основанный на контроллере страницы, где MVC - это подход, основанный на интерфейсном контроллере.Это означает, что в стандартной веб-форме MVP жизненный цикл страницы просто увеличивается за счет извлечения бизнес-логики из кода.Другими словами, страница - это та, которая обслуживает http-запрос.Другими словами, MVP IMHO - это эволюционный тип улучшения веб-формы.С другой стороны, MVC полностью меняет игру, потому что запрос перехватывается классом контроллера до загрузки страницы, бизнес-логика выполняется там, а затем в конечном результате обработки контроллером данные просто сбрасываются на страницу ("просмотр") В этом смысле MVC во многом напоминает (по крайней мере, для меня) MVP-версию контроллера, улучшенную с помощью механизма маршрутизации
Оба они поддерживают TDD и имеют как недостатки, так и плюсы.
Решение о том, как выбрать один из них, ИМХО, должно основываться на том, сколько времени человек вложил в веб-разработку ASP NET web form.Если кто-то считает себя хорошим специалистом в веб-формах, я бы предложил MVP.Если кто-то чувствует себя не очень комфортно в таких вещах, как жизненный цикл страницы и т.д., MVC может быть способом обратиться сюда.
Вот еще одна ссылка на запись в блоге, дающая немного больше подробностей по этой теме
Я использовал как 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.
В этих средах пользовательский интерфейс / HTML5 / XAML знает, какое свойство презентатора отображает каждый элемент пользовательского интерфейса, поэтому, когда вы привязываете представление к презентатору, представление ищет свойства и знает, как извлекать из них данные и как их устанавливать, когда значение изменяется пользователем в пользовательском интерфейсе.
Итак, если, например, модель - это автомобиль, то презентатор - это своего рода автомобильный презентатор, предоставляющий для просмотра свойства автомобиля (год выпуска, производитель, сиденья и т.д.).Представление знает, что текстовое поле с именем "car maker" должно отображать свойство presenter Maker.
Затем вы можете привязать к представлению множество различных типов presenter, все они должны иметь свойство Maker - это может быть самолет, поезд или что угодно еще, представлению все равно.Представление извлекает данные из презентатора - неважно, из какого, - при условии, что оно реализует согласованный интерфейс.
Этот фреймворк привязки, если вы уберете его, на самом деле это контроллер :-)
Итак, вы можете рассматривать MVP как эволюцию MVC.
MVC - это здорово, но проблема в том, что обычно для каждого представления используется свой контроллер.Контроллер A знает, как устанавливать поля обзора A.Если теперь вы хотите, чтобы View A отображал данные модели B, вам нужно, чтобы контроллер A знал модель B, или вам нужен контроллер A для получения объекта с интерфейсом, который похож на MVP, только без привязок, или вам нужно переписать код набора пользовательского интерфейса в контроллере B.
Вывод - MVP и MVC не связаны с шаблонами пользовательского интерфейса, но MVP обычно использует фреймворк привязок, под которым находится MVC.ТАКИМ образом, MVP находится на более высоком архитектурном уровне, чем MVC, и шаблон-оболочка выше MVC.
Мой скромный краткий обзор:MVP предназначен для больших масштабов, а MVC - для крошечных.С MVC я иногда чувствую, что V и C можно рассматривать как две стороны одного неделимого компонента, довольно напрямую связанного с M, и человек неизбежно приходит к этому при переходе к более коротким масштабам, таким как элементы управления пользовательского интерфейса и базовые виджеты.При таком уровне детализации MVP имеет мало смысла.Когда же, наоборот, переходят к более масштабным действиям, правильный интерфейс становится более важным, то же самое касается недвусмысленного распределения обязанностей, и вот появляется MVP.
С другой стороны, это эмпирическое правило масштабирования может иметь очень небольшой вес, когда характеристики платформы благоприятствуют каким-то отношениям между компонентами, как в случае с Web, где кажется, что реализовать MVC проще, чем MVP.
Есть это хорошее видео от дяди Боба, где он вкратце объясняет MVC и MVP в конце.
IMO, MVP - это улучшенная версия MVC, где вы в основном отделяете заботу о том, что вы собираетесь показывать (данные), от того, как вы собираетесь показывать (представление).Presenter включает в себя своего рода бизнес-логику вашего пользовательского интерфейса, неявно навязывает, какие данные должны быть представлены, и предоставляет вам список глупых моделей представления.И когда приходит время отображать данные, вы просто подключаете свое представление (возможно, с теми же идентификаторами) к своему адаптеру и устанавливаете соответствующие поля представления, используя эти модели представления с минимальным количеством вводимого кода (просто используя установщики).Главное преимущество заключается в том, что вы можете протестировать бизнес-логику вашего пользовательского интерфейса на множестве различных представлений, таких как отображение элементов в горизонтальном списке или вертикальном списке.
В MVC мы общаемся через интерфейсы (границы) для склеивания различных слоев.Controller - это подключаемый модуль к нашей архитектуре, но у него нет такого ограничения, чтобы навязывать, что показывать.В этом смысле MVP - это своего рода MVC с концепцией подключаемых к контроллеру представлений через адаптеры.
Надеюсь, это поможет лучше.
Существует много версий MVC, этот ответ посвящен оригинальному MVC в Smalltalk.Вкратце, это
Этот разговор droidcon в Нью-Йорке 2017 - Чистый дизайн приложений с компонентами архитектуры проясняет это
Самый простой ответ заключается в том, как представление взаимодействует с моделью.В MVP представление привязано к презентатору, который выступает посредником между представлением и моделью, принимая входные данные из представления, получая данные из модели, затем выполняя бизнес-логику и, наконец, обновляя представление.В MVC модель обновляет представление напрямую, а не возвращается обратно через контроллер.
Я думаю, что это изображение Эрвина Вандервалька (и сопровождающее его Статья) - лучшее объяснение MVC, MVP и MVVM, их сходств и различий.Тот Самый Статья не отображается в результатах поисковой системы по запросам "MVC, MVP и MVVM", поскольку в названии статьи отсутствуют слова "MVC" и "MVP".;но, я думаю, это лучшее объяснение.
(Тот самый Статья это также соответствует тому, что сказал дядя Боб Мартин в одном из своих выступлений:что MVC изначально был разработан для небольших компонентов пользовательского интерфейса, а не для архитектуры системы)
MVP
MVP расшифровывается как Model - View- Presenter.Это стало очевидным в начале 2007 года, когда Microsoft представила приложения Smart Client для Windows.
Ведущий выполняет роль наблюдателя в MVP, который обязан просматривать события и бизнес-логику на основе моделей.
Привязка события просмотра будет реализована в Presenter из интерфейса просмотра.
View является инициатором ввода данных пользователем, а затем делегирует события Presenter, а presenter обрабатывает привязки событий и получает данные из моделей.
Плюсы: View имеет только пользовательский интерфейс без какой-либо логики Высокий уровень тестируемости
Минусы: Немного сложнее и больше работы при реализации привязок событий
MVC
MVC расшифровывается как Model-View-Controller.Контроллер отвечает за создание моделей и рендеринг представлений с привязкой моделей.
Контроллер является инициатором, и он решает, какой вид отображать.
Плюсы: Акцент на принципе единой ответственности Высокий уровень тестируемости
Минусы: Иногда слишком большая нагрузка на контроллеры, если попытаться отобразить несколько представлений в одном контроллере.
