Сравнение между MVP и MVC [duplicate]
невероятно, что вы можете найти механизм SQL, выполняющий этот ...
WITH sentence AS
(SELECT
stuff,
row = ROW_NUMBER() OVER (ORDER BY Id)
FROM
SentenceType
)
SELECT
sen.stuff
FROM sentence sen
WHERE sen.row = (ABS(CHECKSUM(NEWID())) % 100) + 1
22 ответа
Model-View-Presenter
В MVP ведущий содержит бизнес-логику пользовательского интерфейса для представления. Все вызовы делегата View непосредственно в Presenter. Презентатор также отделен напрямую от представления и разговаривает с ним через интерфейс. Это должно позволить насмехаться над представлением в модульном тесте. Одним из общих атрибутов MVP является то, что должно быть много двухсторонней диспетчеризации. Например, когда кто-то нажимает кнопку «Сохранить», обработчик события делегирует метод «OnSave». Как только сохранение будет завершено, Presenter затем перезвонит View через его интерфейс, чтобы View мог показать, что сохранение завершено.
MVP имеет тенденцию быть очень естественной моделью для достижения разделенного представления в Web Forms. Причина в том, что представление всегда создается во время исполнения ASP.NET. Вы можете узнать больше об обоих вариантах .
Два основных варианта
Пассивный вид: вид настолько тупой, насколько это возможно, и содержит почти нулевую логику. Ведущий - средний человек, который разговаривает с Видом и Моделью. Вид и модель полностью защищены друг от друга. Модель может создавать события, но Presenter подписывается на них для обновления представления. В пассивном представлении нет прямой привязки данных, вместо этого View предоставляет свойства сеттера, которые Presenter использует для установки данных. Все состояние управляется в презентаторе, а не в представлении.
- Pro: максимальная поверхность проверки; чистое разделение View и Model
- Con: больше работы (например, всех свойств сеттера), поскольку вы выполняете все привязки данных самостоятельно.
Контролирующий контроллер: Ведущий обрабатывает жесты пользователя. Вид привязывается к модели непосредственно через привязку данных. В этом случае задача Презентатора заключается в том, чтобы передать модель в представление, чтобы она могла привязываться к ней. Презентатор также будет содержать логику для жестов, таких как нажатие кнопки, навигация и т. Д.
- Pro: при использовании привязки данных количество кода уменьшается.
- Con: существует меньше проверяемой поверхности (из-за привязки данных), и в представлении меньше инкапсуляции, так как она напрямую связана с моделью.
Model-View- Контроллер
В MVC контроллер отвечает за определение того, какой вид отображать в ответ на любое действие, в том числе при загрузке приложения. Это отличается от MVP, где действия маршрутизируются через View to Presenter. В MVC каждое действие в представлении коррелирует с вызовом контроллера вместе с действием. В Интернете каждое действие включает вызов URL-адреса, с другой стороны которого отвечает Контроллер. Как только этот контроллер завершит обработку, он вернет правильный вид. Последовательность продолжается таким образом на протяжении всего срока действия приложения:
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
Еще одна большая разница в MVC заключается в том, что представление напрямую не привязывается к модели. Взгляд просто изображается и полностью без гражданства. В реализациях MVC у View обычно не будет никакой логики в коде. Это противоречит MVP, где это абсолютно необходимо, потому что, если View не передает делегату Presenter, он никогда не будет вызван.
Модель представления
Еще один образец для просмотра является моделью модели представления. В этом шаблоне нет презентатора. Вместо этого представление связывается непосредственно с моделью презентации. Модель представления - это модель, созданная специально для представления. Это означает, что эта модель может выставлять свойства, которые никогда не были бы применены к модели домена, поскольку это было бы нарушением разделения. В этом случае модель представления привязывается к модели домена и может подписаться на события, исходящие из этой Модели. Затем «Вид» подписывается на события, поступающие из модели презентации, и соответственно обновляет их. Модель представления может выставлять команды, которые использует вид для вызова действий. Преимущество этого подхода заключается в том, что вы можете существенно удалить код-код вообще, поскольку PM полностью инкапсулирует все поведение для представления. Этот шаблон является очень сильным кандидатом для использования в приложениях WPF и также называется Model-View-ViewModel .
Существует статья MSDN о модели представления и раздел в Руководстве по композитным приложениям для WPF (бывший Призм) о Разделенные шаблоны презентаций
-
1Не могли бы вы прояснить эту фразу? Это отличается от MVP, где действия маршрутизируются через представление в презентаторе. В MVC каждое действие в представлении коррелирует с вызовом контроллера вместе с действием. Для меня это похоже на одно и то же, но я уверен, что вы описываете что-то другое. – Panzercrisis 19 October 2016 в 13:24
-
2@Panzercrisis Я не уверен, что это то, что имел в виду автор, но это то, что я думаю, что они пытались сказать. Как и этот ответ - stackoverflow.com/a/2068/74556 упоминает, что в MVC методы контроллера основаны на поведении - другими словами, вы можете сопоставить несколько представлений (но такое же поведение) с одним контроллер. В MVP ведущий соединен ближе к представлению и обычно приводит к сопоставлению, которое ближе к взаимно однозначному, т. Е. Действие вида отображает его соответствующий метод ведущего. Обычно вы не сопоставляете действия другого представления другому методу презентатора (из другого представления). – Dustin Kendall 28 October 2016 в 17:50
Многие люди не знают точно, в чем разница между контроллером и презентатором в MVC и MVP соответственно.
его простое уравнение, где
MVC View = Просмотр и Ведущий MVP
MVP Model = Контроллер и модель MVC
больше информации относятся к этому http://includeblogh.blogspot.com.eg/2016/07/the -разностное-и-отношения-between.html
На вопрос много ответов, но я чувствовал, что есть необходимость в каком-то действительно простом ответе, явно сравнивающем эти два вопроса. Вот обсуждение, которое я сделал, когда пользователь ищет имя фильма в приложении MVP и MVC:
Пользователь: нажмите клик ...
Просмотреть : Кто что? [MVP | MVC]
Пользователь: я просто нажал на кнопку поиска ...
Просмотреть : Хорошо, удерживайте секунд .... [MVP | MVC]
( Просмотреть , вызывающий контроллер Presenter | ...) [MVP | MVC]
Просмотреть : Привет Presenter | Контроллер , пользователь только что нажал кнопку поиска, что мне делать? [MVP | MVC]
Presenter | Контроллер : Привет Просмотреть , есть ли поисковый запрос на этой странице? [MVP | MVC]
Посмотреть : Да, ... здесь это ... «фортепиано» [MVP | MVC]
Ведущий : Спасибо Посмотреть , ... тем временем я ищу поисковый запрос на Model , пожалуйста, покажите ему / ей индикатор выполнения [MVP | MVC]
( Presenter | Контроллер вызывает Модель ...) [MVP | MVC]
Ведущий | Контроллер : Привет Модель , есть ли у вас подходящие для этого условия поиска ?: "piano" [MVP | MVC]
Модель : Привет Presenter | Контроллер , позвольте мне проверить ... [MVP | MVC]
( Модель делает запрос к базе данных фильмов ...) [MVP | MVC]
(через некоторое время ...)
---------- ---- Здесь MVP и MVC начинают расходиться ---------------
Модель : я нашел для вас список , Presenter , вот он в JSON «[{« name »:« Piano Teacher »,« year »: 2001}, {« name »:« Piano »,« year »: 1993}] "[MVP]
[g2 8] Модель : Доступен некоторый результат, Controller . Я создал переменную поля в моем экземпляре и заполнил ее результатом. Это имя «searchResultsList» [MVC]
( Presenter | Контроллер благодарит Модель и возвращается к Посмотреть ) [MVP | MVC]
Presenter : Спасибо за ожидание Просмотреть , я нашел список подходящих результатов для вас и устроили их в презентабельном формате: [«Piano Teacher 2001», «Piano 1993»]. Пожалуйста, покажите его пользователю в вертикальном списке. Controller : Спасибо за ожидание Просмотреть , я спросил Model о ваш поисковый запрос. В нем говорится, что он нашел список совпадающих результатов и сохранил их в переменной с именем «searchResultsList» внутри своего экземпляра. Вы можете получить его оттуда. : Большое спасибо Presenter [MVP] ] Просмотреть В случае, если вам интересно, я пишу серия статей, посвященных архитектурным моделям приложений (MVC, MVP, MVVP, чистая архитектура, ...), сопровождаемая репутацией Github здесь . Несмотря на то, что образец написан для андроида, основные принципы могут быть применены к любому средству.
-
1– Radu 28 August 2018 в 14:37
-
2– Ali Nem 28 August 2018 в 22:48
-
3– Tommy Andersen 22 October 2018 в 12:50
- MVP = Model-View-Presenter
- MVC = Model-View-Controller Оба шаблона представления. Они разделяют зависимости между моделью (думаю объекты домена), ваш экран / веб-страницу (вид) и то, как должен работать ваш пользовательский интерфейс (Presenter / Controller). Они довольно схожи по понятию, люди инициализируют Presenter / Controller по-разному в зависимости от вкуса. Замечательная статья о различиях здесь здесь . Наиболее примечательно, что в шаблоне MVC есть модель, обновляющая представление.
-
1
Вот иллюстрации, которые представляют собой поток связи
[/g0] 
[/g1]
-
1У меня вопрос относительно диаграммы MVC. Я не получаю ту часть, в которой просматривается представление данных. Я думаю, что контроллер перейдет к представлению с необходимыми данными. – Brian Rizo 12 May 2015 в 21:07
-
2Если пользователь нажимает кнопку, как это не взаимодействует с представлением? Я чувствую, что в MVC пользователь взаимодействует с представлением больше, чем контроллер – Jonathan 12 August 2015 в 03:28
-
3Я знаю, что это старый ответ, но может ли кто-нибудь ответить на @JonathanLeaders? Я прихожу с фона winforms, если вы не сделали очень уникальное кодирование, когда вы нажимаете UI / View, узнаете об этом щелчке перед чем-либо еще. По крайней мере, насколько я знаю? – Rob P. 4 January 2016 в 15:44
-
4@RobP. Я думаю, что эти типы диаграмм всегда слишком сложны или слишком просты. Imo поток MVP-диаграммы также справедлив для приложения MVC. Могут быть изменения в зависимости от особенностей языков (привязка данных / наблюдателя), но в конце концов идея состоит в том, чтобы отделить представление от данных / логики приложения. – Luca Fülbier 17 January 2016 в 10:37
-
5@JonathanLeaders Люди имеют действительно разные вещи, когда говорят «MVC». Человек, создавший эту диаграмму, имел в виду, вероятно, классический веб-MVC, где «пользовательский ввод» являются HTTP-запросами, и "просмотр возвращается пользователю" представляет собой отображаемую HTML-страницу. Таким образом, любое взаимодействие между пользователем и представлением «отсутствует» & quot; с точки зрения автора классического приложения Web MVC. – cubuspl42 12 June 2016 в 14:38
MVC (Model View Controller)
Вход направляется сначала на контроллер, а не на вид. Этот вход может исходить от пользователя, взаимодействующего со страницей, но также может быть просто введением определенного URL-адреса в браузер. В любом случае, это Контроллер, который сопряжен с возможностью запуска некоторых функций. Между контроллером и представлением существует взаимосвязь «один-к-одному». Это связано с тем, что один контроллер может выбирать различные представления для визуализации на основе выполняемой операции. Обратите внимание на стрелку в одну сторону от контроллера до View. Это связано с тем, что представление не имеет никакого знания или ссылки на контроллер. Контроллер действительно возвращает модель, поэтому между представлением и ожидаемой моделью передаются знания, но не Контроллер, обслуживающий его.
MVP (Model View Presenter)
Вход начинается с представления, а не с презентатора. Существует сопоставление «один к одному» между представлением и ассоциированным презентатором. В представлении содержится ссылка на презентатора. Презентатор также реагирует на события, которые запускаются из представления, поэтому он знает, что связано с ним. Презентатор обновляет представление на основе запрошенных действий, которые он выполняет в модели, но представление не относится к модели.
Для получения дополнительных ссылок
-
1Но в шаблоне
MVP, когда приложение загружается в первый раз, разве презентатор не отвечает за загрузку первого представления? Как, например, когда мы загружаем приложение facebook, не является ли ведущий ответственным за загрузку страницы входа? – viper 11 November 2016 в 06:18 -
2Ссылка с модели на просмотр в MVC? Вы можете отредактировать свой ответ, чтобы объяснить, как это делает его «развязанной» системой, учитывая эту ссылку. Подсказка: вам это может показаться трудным. Кроме того, если вы не считаете, что читатель с радостью согласится, что они неправильно вычисляют всю свою жизнь, вы можете уточнить, почему действия проходят через контроллер сначала в MVC, несмотря на то, что пользователь взаимодействует с «визуальными» элементами на экране (т. Е. View), а не некоторый абстрактный слой, который стоит за обработкой. – Ash 5 June 2017 в 02:32
-
3
-
4– MegaManX 25 October 2018 в 12:39
Самый простой ответ заключается в том, как представление взаимодействует с моделью. В MVP представление привязано к ведущему, которое действует как посредник между представлением и моделью, принимает входные данные из представления, получает данные из модели, затем выполняет бизнес-логику и, наконец, обновляет представление. В MVC модель обновляет представление напрямую, а не возвращается через контроллер.
Мой скромный короткий взгляд: MVP для больших масштабов и MVC для крошечных масштабов. С MVC я когда-то ощущаю, что V и C могут видеть две стороны одного неделимого компонента, скорее привязанного к M, и неизбежно падает на это, когда он идет вниз - в более короткие масштабы, такие как элементы управления пользовательского интерфейса и базовые виджеты. На этом уровне детализации MVP имеет мало смысла. Когда кто-то, наоборот, переходит в более крупные масштабы, правильный интерфейс становится более важным, то же самое с однозначным назначением обязанностей, и здесь идет MVP.
С другой стороны, это правило шкалы большого пальца может иметь вес очень мало, когда характеристики платформы благоприятствуют каким-то отношениям между компонентами, например, с сетью, где, по-видимому, проще реализовать MVC, больше, чем MVP.
MVP
MVP означает Model-View-Presenter. Это появилось в начале 2007 года, когда Microsoft представила приложения Windows Smart Client.
Presenter выступает в роли контрольной роли в MVP, которая связывает просмотр событий и бизнес-логики с моделями.
Просмотр привязки события будет реализован в Presenter из интерфейса представления.
View является инициатором для пользовательских входов, а затем делегирует события в Presenter и ведущий обрабатывает привязки событий и получает данные из моделей.
Плюсы: View имеет только UI, а не логики High уровень тестируемости
Минусы: бит сложный и больше работы при реализации привязок событий
MVC
MVC означает Model-View-Controller. Контроллер отвечает за создание моделей и просмотр представлений с помощью моделей привязки.
Контроллер является инициатором, и он решает, какой вид рендеринга.
Плюсы: Акцент на принципах единой ответственности Высокий уровень тестируемости
Минусы: Иногда слишком большая рабочая нагрузка для контроллеров, если пытаться отображать несколько просмотров в одном контроллере.
Обе эти структуры направлены на разделение проблем - например, взаимодействие с источником данных (моделью), логикой приложения (или превращением этих данных в полезную информацию) (контроллер / презентатор) и отображаемым кодом (вид). В некоторых случаях модель также может использоваться для превращения источника данных в абстракцию более высокого уровня. Хорошим примером этого является проект MVC Storefront .
Здесь обсуждается здесь относительно различий между MVC и MVP.
Сделанное различие заключается в том, что в приложении MVC традиционно есть представление, и контроллер взаимодействует с моделью, но не друг с другом.
Конструкции MVP имеют Presenter для доступа к модели и взаимодействия с представлением.
Сказав, что ASP.NET MVC по этим определениям представляет собой структуру MVP, потому что Controller обращается к Модели, чтобы заполнить представление, которое не имеет логики (просто отображает переменные, предоставляемые контроллером).
Чтобы, возможно, получить представление об отличии ASP.NET MVC от MVP, посмотрите эту презентацию MIX Скотта Гензельмана.
-
1MVC и MVP - это шаблоны, а не рамки. Если вы честно думаете, что эта тема была о платформе .NET, то это похоже на прослушивание «Интернет». и думает, что это о IE. – tereško 18 June 2012 в 18:26
-
2Довольно уверен, что этот вопрос значительно изменился после того, как его впервые попросили еще в 2008 году. Кроме того, оглядываясь назад на мой ответ (а это было 4 года назад, поэтому у меня не было больше контекста, чем у вас), я бы сказал, что я начинаю вообще и затем используйте .NET MVC в качестве конкретного примера. – Matt Mitchell 19 June 2012 в 06:08
Оба являются шаблонами, пытающимися отделить презентационную и бизнес-логику, отделяя бизнес-логику от аспектов пользовательского интерфейса
Архитектурно, MVP - это подход, основанный на использовании Page Controller, где MVC - подход на основе Front Controller. Это означает, что в стандартном веб-формате MVP жизненный цикл страницы просто усиливается путем извлечения бизнес-логики из кода позади. Другими словами, страница является одним из обслуживающих HTTP-запросов. Другими словами, MVP IMHO является эволюционным типом расширения веб-формы. MVC с другой стороны полностью изменяет игру, потому что запрос перехватывается классом контроллера до загрузки страницы, бизнес-логика выполняется там, а затем в конечном результате контроллера обрабатывает данные, только что сбрасываемые на страницу («вид»). В этом смысл, MVC (по крайней мере, мне) много смотрит на Supervising Controller вкус MVP, улучшенный с помощью механизма маршрутизации
. Оба из них позволяют TDD и имеют недостатки и недостатки.
Решение о том, как выбрать один из них, должно быть основано на том, сколько времени было потрачено на создание веб-формы веб-формы ASP NET. Если бы вы считали себя хорошим в веб-формах, я бы предложил MVP. Если бы вы чувствовали себя не так комфортно в таких вещах, как жизненный цикл страницы и т. Д. MVC мог бы быть здесь.
Вот еще одна ссылка для блога, дающая немного более подробную информацию по этой теме
Существует много версий MVC, этот ответ касается исходного MVC в Smalltalk. Короче говоря, это
Этот разговор droidcon NYC 2017 - Чистый дизайн приложения с компонентами архитектуры разъясняет его
-
1
-
2
-
3Это неверный ответ. Не вводите в заблуждение. как пишет @rodi, между View и Model нет взаимодействия. – Shawn Mehan 18 November 2015 в 19:35
-
4Изображение MVC неточно или, в лучшем случае, вводит в заблуждение, пожалуйста, не обращайте внимания на этот ответ. – Jay1b 7 December 2015 в 16:21
-
5@ Jay1b Какой MVC вы считаете правильным? Этот ответ касается оригинального MVC. Существует много других MVC (как в iOS), которые были изменены для адаптации к платформе, например
UIKit– onmyway133 14 November 2017 в 15:08
Я использовал 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 или различные рамки привязки для HTML5 и Java.
В этих рамках пользовательский интерфейс / HTML5 / XAML знает, какое свойство презентатора отображает каждый элемент пользовательского интерфейса, поэтому, когда вы привязываете представление к ведущему, представление ищет свойства и знает, как извлекать данные из них и как их устанавливать, когда пользовательское значение изменяется в пользовательском интерфейсе.
Итак, если, например, модель представляет собой автомобиль, то ведущий - это своего рода автомобиль ведущий, раскрывает свойства автомобиля (год, производитель, места и т. д.). Представление знает, что текстовое поле, называемое «автопроизводителем», должно отображать свойство создателя презентатора.
Затем вы можете привязать к представлению много разных типов презентаторов, все должны иметь свойство Maker - это может быть самолет, поезд или что-то еще, представление не заботится. В представлении представлены данные от ведущего - независимо от того, что - пока он реализует согласованный интерфейс.
Эта привязка, если вы ее разделите, это на самом деле контроллер :-)
Итак, вы можете посмотреть MVP как эволюцию MVC.
MVC замечательный, но проблема в том, что обычно его контроллер на просмотр. Контроллер A знает, как установить поля View A. Если теперь вы хотите, чтобы View A отображал данные модели B, вам нужен контроллер A, чтобы знать модель B, или вам нужен контроллер A для получения объекта с интерфейсом - это похоже на MVP только без привязок, или вам нужно переписать набор UI-кода в контроллере B.
Заключение. MVP и MVC являются как развязкой шаблонов пользовательского интерфейса, но MVP обычно использует фреймворк привязок, который является MVC снизу. THUS MVP находится на более высоком архитектурном уровне, чем MVC, и шаблон оболочки выше MVC.
-
1«Просмотр не знает о контроллере». Я думаю, вы имеете в виду, что точка зрения не имеет прямого контакта с моделью? – Lotus Notes 25 March 2010 в 08:51
-
2
-
3Я не понимаю, как в представлении могут быть более или менее тесно связаны с моделью, когда в обоих случаях вся цель состоит в том, чтобы полностью отделить их. Я не подразумеваю, что вы сказали что-то не так - просто путайте, что вы имеете в виду. – Bill K 5 October 2011 в 01:25
-
4@pst: с MVP это действительно 1 View = 1 Presenter. С MVC контроллер может управлять несколькими видами. Вот и все. С вкладками " модель представляет себе каждую вкладку, имеющую собственный докладчик, а не один контроллер для всех вкладок. – Jon Limjap 29 June 2012 в 10:46
-
5@Brian: «В большинстве случаев представление создает его« Ведущий ». В основном я видел противоположное, когда Presenter запускал как модель, так и представление. Ну, View может запустить Presenter тоже, но этот момент не самый отличительный. Самое главное, что происходит на протяжении жизни. – Hibou57 20 February 2013 в 17:55
-
6Первоначально существуют два типа контроллеров: тот, который, как вы сказали, разделяется между несколькими представлениями, и теми, кто определен как просмотр, в основном предназначенный для адаптации интерфейса совместно используемого контроллера. – Acsor 11 November 2013 в 16:12
-
7@JonLimjap Что это значит, по одному виду? В контексте программирования iOS это одно-экранный? Означает ли это, что контроллер iOS больше похож на MVP, чем MVC? (С другой стороны, вы также можете иметь несколько контроллеров iOS на экран) – huggie 19 March 2014 в 09:55
-
8Схематическая иллюстрация MVD Тодда полностью противоречит идее развязки зрения и модели. Если вы посмотрите на диаграмму, в нем отображается «Просмотр обновления модели» (стрелка от «Модель к представлению»). В какой юниверсе есть система, где модель напрямую взаимодействует с представлением, развязанным? – Ash 4 June 2017 в 02:01
-
9Вы можете отредактировать свой ответ, чтобы объяснить далее: поскольку представление не знает о контроллере, как выполняются действия пользователя, которые выполняются на «визуальных» элементах, которые пользователь видит на экране (т. Е. В представлении), передаются контроллеру ... – Ash 5 June 2017 в 05:21
Это упрощение многих вариантов этих шаблонов проектирования, но это то, как мне нравится думать о различиях между ними.
MVC
[/g0]
MVP
[/g1]
-
1Это отличное изображение схемы, показывающее абстракцию и полную изоляцию любого связанного с GUI (представления) из API ведущего. Одна второстепенная точка: мастер-презентатор может использоваться там, где есть только один ведущий, а не один на просмотр, но ваша диаграмма является самой чистой. IMO, самая большая разница между MVC / MVP заключается в том, что MVP пытается полностью игнорировать представление, отличное от отображения текущего состояния просмотра (просмотр данных), а также запрещает представление любого знания объектов модели. Таким образом, интерфейсы, которые должны быть там, должны вводить это состояние. – user 15 October 2013 в 04:30
-
2Хорошая картина. Я использую MVP довольно много, поэтому я хотел бы сделать одно очко. По моему опыту, докладчикам нужно часто разговаривать друг с другом. То же самое верно для моделей (или бизнес-объектов). Из-за этих дополнительных "синих линий" связи, которая была бы в вашем MVP-файле, отношения между презентатором и моделью могут стать довольно запутанными. Поэтому я склонен поддерживать отношения «один к одному» между презентатором и моделью по сравнению с «один ко многим». Да, это требует некоторых дополнительных методов делегирования для Модели, но это уменьшает многие головные боли, если API Модели изменяется или нуждается в рефакторинге. – splungebob 28 February 2014 в 16:45
-
3Пример MVC неверен; существует строгая связь 1: 1 между представлениями и контроллерами. По определению контроллер интерпретирует ввод жестов человека для создания событий для модели и просмотра для одного элемента управления. Более просто, MVC был предназначен для использования только с отдельными виджетами. Один виджет, один вид, один элемент управления. – Samuel A. Falvo II 5 April 2014 в 16:34
-
4@ SamuelA.FalvoII не всегда, есть 1: много между контроллерами и представлениями в ASP.NET MVC: stackoverflow.com/questions/1673301/… – StuperUser 7 January 2016 в 18:57
-
5@StuperUser - Не уверен, что я думал, когда писал это. Вы правы, конечно, и оглядываясь назад на то, что я написал, мне нужно подумать, есть ли у меня какой-то другой контекст, который я не смог сформулировать. Спасибо за исправление. – Samuel A. Falvo II 12 January 2016 в 00:40
MVP - not обязательно сценарий, в котором отображается представление (см., например, MVP Taligent). Мне доставляет сожаление, что люди по-прежнему проповедуют это как образец (вид в целом), а не анти-шаблон, поскольку он противоречит «Это просто взгляд» (прагматический программист). «Это просто представление» указывает, что конечное представление, отображаемое пользователю, является вторичной проблемой приложения. Microsoft MVP-шаблон делает повторное использование Views намного более сложным, а удобно оправдывает конструктор Microsoft от поощрения плохой практики.
Чтобы быть абсолютно откровенным, я думаю, что основные проблемы MVC верны для любой реализации MVP, и различия почти полностью семантичны. До тех пор, пока вы будете разделять проблемы между представлением (которое отображает данные), контроллер (который инициализирует и контролирует взаимодействие с пользователем) и модель (базовые данные и / или услуги)), тогда вы получаете преимущества MVC , Если вы получаете преимущества, то кто действительно заботится о том, является ли ваш шаблон MVC, MVP или контролером? Единственная реальная модель остается как MVC, остальные - просто разные ее ароматы.
Рассмотрим эту очень интересную статью, в которой полно перечислены некоторые из этих различные реализации. Вы можете заметить, что все они в основном делают одно и то же, но немного по-другому.
Я лично считаю, что MVP недавно был вновь представлен как броский термин, чтобы либо уменьшить аргументы между семантическими фанатиками, которые утверждают, действительно MVC или нет, или для оправдания инструментов быстрой разработки приложений Microsoft. Ни одна из этих причин в моих книгах не оправдывает его существование как отдельный шаблон дизайна.
-
1Я прочитал несколько ответов и блоги о различиях между MVC / MVP / MVVM / etc. Фактически, когда вы не занимаетесь бизнесом, все равно. На самом деле не имеет значения, есть ли у вас интерфейс или нет, и используете ли вы установщик (или любую другую функцию языка). Похоже, что различие между этими образцами рождалось из разницы различных реализаций фреймворков, а не из понятия. – Michael 7 March 2011 в 23:36
-
2Я бы не назвал MVP a anti-pattern , как позже в post ".. остальные [включая MVP] - это просто разные ароматы [MVC] ..", что означало бы, что если MVP был анти-шаблоном, то был MVC ... это просто аромат для подхода другой структуры. (Теперь некоторые конкретные MVP-реализации могут быть более или менее желательными, чем некоторые конкретные MVC-реализации для разных задач ...) – user 15 June 2012 в 20:31
-
3@Quibblsome: «Я лично считаю, что MVP недавно был недавно введен в качестве броского термина, чтобы либо уменьшить аргументы между семантическими фанатиками, которые утверждают, что-то действительно MVC, либо нет [...] Ни одна из этих причин в моих книгах оправдывает его существование как отдельный шаблон дизайна. ". Он достаточно различен, чтобы сделать его отличным. В MVP представление может быть любым, выполняющим предопределенный интерфейс (представление в MVP является автономным компонентом). В MVC Controller создан для определенного вида (если атрибуты отношения могут заставить кого-то почувствовать, что это стоит другого термина). – Hibou57 20 February 2013 в 17:50
-
4@ Hibou57, нет ничего, чтобы остановить MVC от ссылки на представление в виде интерфейса или создания универсального контроллера для нескольких разных видов. – Quibblesome 22 February 2013 в 18:34
-
5@quibblesome на самом деле, есть. Контроллеры по определению тесно связаны с их соответствующими представлениями, поскольку их работа заключается в том, чтобы интерпретировать человеческие жесты (нажатия клавиш, обновления мыши и т. Д.) В события для отдельных элементов управления в окне. Вот почему у вас строгий один контроллер, один вид отношения. Контроллеры были never , предназначенные для использования в форме. Для использования в форме формы появилась модель приложения (например, модель представления), которая лучше подходит для этой цели. Поскольку GUI не-Smalltalk не полагаются на MVC для реализации элементов управления, MVC практически не имеет смысла на практике. – Samuel A. Falvo II 5 April 2014 в 16:31
Model-View-Controller
MVC - это шаблон для архитектуры программного приложения. Он разделяет логику приложения на три отдельные части, способствуя модульности и простоте совместной работы и повторного использования. Это также делает приложения более гибкими и приветственными итерациями. Он отделяет приложение от следующих компонентов:
- Модели обработки данных и бизнес-логики
- Контроллеры для обработки пользовательского интерфейса и приложение
- Представления для обработки объектов графического интерфейса пользователя и презентации
Чтобы сделать это более понятным, представим простое приложение списка покупок. Все, что мы хотим, это список имен, количества и цены каждого предмета, который нам нужно купить на этой неделе. Ниже мы опишем, как реализовать некоторые из этих функций с помощью MVC.
Model-View-Presenter
- Модель - это данные, которые будут отображаться в представлении (пользовательский интерфейс).
- Вид представляет собой интерфейс, который отображает данные (модель) и маршрутизирует пользовательские команды (события) в Ведущий, чтобы действовать по этим данным. Представление обычно имеет ссылку на его презентатор.
- Presenter - это «средний человек» (воспроизводится контроллером в MVC) и имеет ссылки как на просмотр, так и на модель. Обратите внимание, что слово «модель» вводит в заблуждение. Это скорее бизнес-логика, которая извлекает или манипулирует моделью. Например: если у вас есть база данных, хранящая User в таблице базы данных, и ваш View хочет отобразить список пользователей, то Presenter будет ссылаться на вашу бизнес-логику базы данных (например, DAO), откуда Presenter будет запрашивать список пользователей.
Если вы хотите увидеть образец с простой реализацией, проверьте этот пост github
Конкретный рабочий процесс запроса и отображения списка пользователей из базы данных может работать следующим образом:
В чем разница между шаблонами MVC и MVP?
MVC Pattern
- Контроллер основан на поведении и может быть разделен между представлениями
- Может нести ответственность за определение отображаемого вида (Front Controller Pattern )
MVP Pattern
- Вид более слабо связан с моделью. Ведущий отвечает за привязку модели к представлению.
- Легче тестировать модуль, потому что взаимодействие с представлением осуществляется через интерфейс
- Обычно просматривайте карту презентатора один к одному. Сложные представления могут иметь несколько презентаторов.
В android есть версия mvc, которая является mvp: Что такое MVP?
Шаблон MVP позволяет отделить уровень представления от логики, так что все, о чем работает интерфейс, отделяется от того, как мы представить его на экране. В идеале шаблон MVP достигнет той же логики, которая может иметь совершенно разные и взаимозаменяемые представления.
Прежде всего, чтобы уточнить, MVP не является архитектурным шаблоном, он отвечает только за уровень представления. В любом случае всегда лучше использовать его для вашей архитектуры, которая вообще не использует его.
Примером для mvp является https://github.com/antoniolg/androidmvp
Что такое MVC? Архитектура MVC является одной из самых старых моделей, доступных для достижения разделения проблем. MVC состоит из трех уровней: Model, View и Controller.
Классический MVC существовал в то время, когда каждый элемент управления / гаджет, который существовал на экране, считался немым, и каждый элемент управления был сопряжен с собственным контроллером для управления взаимодействием пользователей с ними. Поэтому, если 10 гаджетов существуют, то 10 контроллеров должны существовать. В этом случае каждый гаджет считается представлением. Появление систем Windows GUI изменило эту картину. Отношение Control-Controller стало устаревшим. Элементы управления получили интеллект, чтобы реагировать на действия, инициированные пользователем. В мире Windows вид - это поверхность, на которой все элементы управления / гаджеты существуют, поэтому существует потребность только в одном контроллере. Просмотр может получать события и получать доступ к контроллерам для дальнейшей обработки.
Пример кода для mvc в android http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription& help = 116 & amaid; aaid = 138
Разница между ними доступна здесь http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP -for-Beginners
Теперь из моего опыта вы должны использовать MVP для проекта на основе андроида, потому что это улучшенная версия MVC Model.
-
1
Что-то я не понимаю, поэтому привязка данных имеет , чтобы уменьшить тестируемость. Я имею в виду, что представление эффективно основывается на том, что можно рассматривать как один или несколько представлений базы данных, не так ли? Там могут быть соединения между строками в разных представлениях. В качестве альтернативы мы можем говорить объектно-ориентированной, а не реляционной, но это на самом деле ничего не меняет - у нас все еще есть один или несколько различных объектов данных.
Если мы рассматриваем программирование как структуры данных + алгоритмы, то не было бы лучше, если бы структуры данных были ясными максимально возможными, а затем разрабатывали алгоритмы, в которых каждая из них зависела как можно меньшим количеством данных, с минимальной связью между алгоритмами?
Я чувствую очень Java-esque FactoryFactoryFactory мыслей здесь - мы хотим иметь множество представлений, несколько моделей, множество степеней свободы повсюду. Это почти так, что это движущая сила MVC и MVP и еще много чего. Теперь позвольте мне спросить: как часто вы платите за это (и определенно ли стоит стоимость)?
Я также не вижу обсуждения того, как эффективно управлять состоянием между HTTP-запросами. Разве мы не узнали от функциональных людей (и объемных ошибок, сделанных императивными спагетти), что состояние является злым и должно быть сведено к минимуму (и когда оно используется, должно быть хорошо понято)?
Я вижу много использование терминов MVC и MVP без значительных доказательств того, что люди критически относятся к ним. Ясно, что проблема заключается в «их», мне или обоим ...
-
1Я работал над MVC-ином в очень простых средах. Это не должно усложнять ситуацию. Это дает вам очень последовательные рекомендации о том, как организовать свой код таким образом, чтобы впоследствии не сосать. Нет причин бросать чрезмерные степени свободы - M + V + C может быть плотно соединен и все еще хорош (потому что M и V независимо проверяются). – Tom 12 January 2011 в 15:41
Каждый из них адресует разные проблемы и может даже быть объединен вместе, чтобы иметь что-то вроде ниже
[/g1]
. Также имеется полное сравнение MVC, MVP и MVVM здесь
Это это приятное видео от дяди Боба, где он кратко объясняет MVC & amp; MVP в конце.
IMO, MVP - это улучшенная версия MVC, в которой вы в основном отделяете внимание от того, что вы собираетесь показать (данные) из того, как вы собираетесь показывать (представление). Презентатор включает в себя любопытную бизнес-логику вашего пользовательского интерфейса, неявно налагает, какие данные должны быть представлены, и дает вам список немого вида. И когда придет время показать данные, вы просто подключите свое представление (возможно, включает в себя те же идентификаторы) в свой адаптер и установите соответствующие поля просмотра, используя эти модели просмотра с минимальным количеством вводимого кода (просто используя сеттеры). Главное преимущество заключается в том, что вы можете протестировать свою бизнес-логику пользовательского интерфейса против множества / разных видов, например, показывать элементы в горизонтальном списке или вертикальном списке.
В MVC мы говорим через интерфейсы (границы), чтобы склеить разные слои. Контроллер является плагином для нашей архитектуры, но у него нет такого ограничения, чтобы навязывать, что показывать. В этом смысле MVP является своего рода MVC с концепцией представлений, которые могут быть подключены к контроллеру через адаптеры.
Надеюсь, это поможет лучше.