Що таке MVP і MVC і в чому різниця?

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

1. Які питання вирішують ці зразки?
2. Чим вони схожі?
3. Чим вони відрізняються?

Model-View-Presenter

У MVP презентатор містить бізнес-логіку інтерфейсу користувача для представлення даних. Усі виклики від представника перегляду безпосередньо в Presenter. Презентатор також відокремлюється безпосередньо від Погляду та спілкується з ним через інтерфейс. Це дозволяє дозволити знущання з виду в одиничному тесті. Одним загальним атрибутом MVP є те, що повинно бути багато двосторонньої диспетчеризації. Наприклад, коли хтось натискає кнопку "Зберегти", обробник подій делегує методу "OnSave" презентатора. Після того, як збереження завершено, Презентатор передзвонить Перегляд через його інтерфейс, щоб Перегляд міг відобразити, що збереження завершено.

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

Дві основні варіанти

Пасивний вид: Вид є максимально німим і містить майже нульову логіку. Ведучий - це середня людина, яка розмовляє з Поглядом та Моделлю. Вид і модель повністю захищені одна від одної. Модель може викликати події, але Ведучий підписується на них для оновлення Перегляду. У пасивному перегляді немає прямого прив'язки даних, натомість представлення відкриває властивості сеттера, які Presenter використовує для встановлення даних. Увесь стан керується в Presenter, а не у Перегляді.

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

Контролер контролера: Презентатор обробляє жести користувачів. Вид прив'язується до Моделі безпосередньо за допомогою прив'язки даних. У цьому випадку завдання Ведучого передавати Модель на вид, щоб вона могла прив’язатись до неї. Презентатор також містить логіку для жестів, таких як натискання кнопки, навігація тощо.

• Про: за допомогою використання прив'язки даних кількість коду зменшується.
• Con: там менш тестова поверхня (через зв’язування даних), і менше виду капсуляції у Перегляді, оскільки він спілкується безпосередньо з Модель.

Модель-перегляд-контролер

У MVC контролер відповідає за визначення того, який вид відображати у відповідь на будь-яку дію, в тому числі, коли програма завантажується. Це відрізняється від MVP, коли дії рухаються через Перегляд до Презентатора. У MVC кожна дія у Перегляді співвідноситься з викликом до контролера разом із дією. У Інтернеті кожна дія включає виклик до URL-адреси, з іншого боку якої є Контролер, який відповідає. Після того як цей контролер завершить обробку, він поверне правильний вигляд. Послідовність продовжується таким чином протягом усього життя програми:

    Дія у виду
        -> Виклик контролера
        -> Логіка контролера
        -> Контролер повертає Вид.

Ще одна велика відмінність щодо MVC полягає в тому, що вид не безпосередньо прив'язується до моделі. Вигляд просто видається і є абсолютно бездержавним. У реалізаціях MVC View зазвичай не матиме логіки в коді позаду. Це суперечить MVP, коли це абсолютно необхідно, тому що, якщо Перегляд не делегує Презентатору, він ніколи не зателефонує.

Презентаційна модель

Ще одна модель, на яку слід звернути увагу - це Презентаційна модельвізерунок. У цій схемі немає презентації. Натомість перегляд пов'язується безпосередньо з презентаційною моделлю. Модель презентації - це модель, створена спеціально для представлення. Це означає, що ця Модель може виявити властивості, які ніколи не було б застосовано до доменної моделі, оскільки це було б порушенням роз'єднаності проблем. У цьому випадку презентаційна модель прив'язується до доменної моделі і може підписатися на події, що надходять із цієї моделі. Потім "Перегляд" підписується на події, що надходять із презентаційної моделі, та оновляється відповідно. Модель презентації може розкривати команди, які подання використовує для виклику дій. Перевага такого підходу полягає в тому, що ви можете по суті видалити код позаду, оскільки PM повністю інкапсулює всю поведінку для перегляду.Model-View-ViewModel .

Є стаття MSDN про модель презентації та розділ у складеному Посібнику щодо застосування WPF (колишня призма) про розділені шаблони презентації.

Це надмірне спрощення багатьох варіантів цих моделей дизайну, але саме так мені подобається думати про відмінності між ними.

MVC

MVP

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

Ось ключові відмінності між моделями:

MVP Pattern

• Вид більш вільно поєднується з моделлю. Ведучий відповідає за прив'язку моделі до перегляду.
• Легше перевірити блок, оскільки взаємодія з представленням здійснюється через інтерфейс
• Зазвичай перегляд карти ведучого один на один. Складні перегляди можуть мати кілька презентантів.

MVC Шаблон

• Контролер базується на поведінці та може бути поділений у різних поглядах
• Може нести відповідальність за визначення того, який вид відображати

Це найкраще пояснення в Інтернеті, яке я міг знайти.

Ось ілюстрації, які представляють потік зв'язку

MVP - це не обов'язково сценарій, коли перегляд відповідає (див. Наприклад MVP Taligent).
Мені прикро, що люди все ще проповідують це як зразок (Перегляд відповідальності) на відміну від анти-зразка, оскільки він суперечить "Це просто погляд" (Прагматичний програміст). "Це просто перегляд" зазначає, що остаточний вигляд, показаний користувачеві, є другорядним питанням програми. Модель MVP від ​​Microsoft значно ускладнює повторне використання поглядів та зручно виправдовує дизайнера Microsoft від заохочення до поганої практики.

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

Розглянемо цю надзвичайно захоплюючу статтю, яка всебічно перераховує ряд цих різних реалізацій. Ви можете зауважити, що всі вони роблять те саме, але трохи інакше.

Я особисто думаю, що MVP був нещодавно введений знову як привабливий термін, щоб зменшити аргументи між семантичними фанатиками, які аргументують, чи щось справді MVC чи ні, або щоб виправдати інструменти швидкого розвитку додатків Microsofts. Жодна з цих причин у моїх книгах не виправдовує її існування як окрему модель дизайну.

MVP: перегляд відповідає.

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

MVC: контролер відповідає.

Контролер створюється або отримує доступ до нього на основі якоїсь події / запиту. Потім контролер створює відповідний вигляд і взаємодіє з моделлю для подальшого налаштування подання. Він зводиться до: контролер створює та управляє поданням; погляд є рабом контролера. Погляд не знає про контролер.

MVC (контролер перегляду моделі)

Вхід спрямовується спочатку на контролер, а не на вигляд. Цей вхід може надходити від користувача, який взаємодіє зі сторінкою, але це може бути і просто введенням певного URL-адреса в браузер. У будь-якому випадку, це контролер, з яким пов'язаний, щоб розпочати деяку функціональність. Між контролером і видом існує взаємозв'язок між собою. Це тому, що один контролер може вибрати різні подання для відображення на основі операції, що виконується. Зверніть увагу на стрілку в одну сторону від Controller to View. Це пояснюється тим, що представлення даних не має жодних знань про контролер або посилання на нього. Контролер передає Модель назад, тому є знання між Переглядом і очікуваною моделлю, що передається в неї, але не Контролером, який її обслуговує.

MVP (презентатор подання моделі)

Введення починається з представлення даних, а не з презентатора. Існує відображення «один на один» між Переглядом та пов’язаним з ним презентатором. Перегляд містить посилання на ведучого. Ведучий також реагує на події, викликані з Перегляду, тому він усвідомлює Перегляд, з яким пов'язаний. Презентатор оновлює Перегляд на основі запитуваних дій, які він виконує на Моделі, але Перегляд не відомий моделі.

Для отримання більш докладної посилання

Відповідей на це питання багато, але я відчув, що потрібна справді проста відповідь, чітко порівнюючи обидві. Ось дискусія, яку я підготував, коли користувач шукає ім’я фільму в додатках MVP та MVC:

Користувач: натисніть кнопку ...

Вид : Хто це? [ МВП | MVC ]

Користувач: Я просто натиснув кнопку пошуку ...

Перегляд : Гаразд, зачекай на секунду…. [ МВП | MVC ]

( Переглянути виклик презентатора | Контролер ...) [ MVP |MVC ]

Вид : Ей, ведучий | Контролер , Користувач щойно натиснув на кнопку пошуку, що робити? [ МВП |MVC ]

Ведучий | Контролер : Гей Подивитися , чи є термін пошуку на цій сторінці? [ МВП | MVC ]

Вид : Так,… ось воно… “фортепіано” [ MVP | MVC ]

Ведучий : Дякую Перегляд ,… тим часом я шукаю пошуковий термін на Моделі , покажіть його, будь ласка, панель прогресу [ MVP | MVC ]

( Ведучий | Контролер викликає модель …) [ MVP | MVC ]

Ведучий | Контролер : Ей, модель , чи є у вас відповідність для цього пошукового терміна ?: "фортепіано" [ MVP | MVC ]

Модель : Hey Presenter | Контролер , дозвольте мені перевірити… [ MVP |MVC ]

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

( Невдовзі ... )

-------------- Тут MVP і MVC починають розходитися ---------------

Модель : Я знайшов список для вас, ведучий , ось він у JSON "[{" ім'я ":" Вчитель фортепіано "," рік ": ​​2001}, {" ім'я ":" Піаніно "," рік ": ​​1993} ] ”[ MVP ]

Модель : Є деякий результат, контролер . Я створив змінну поля у своєму екземплярі і заповнив її результатом. Його назва - "searchResultsList" [ MVC ]

( Ведучий | Контролер дякує Моделі та повертається до Перегляду ) [ MVP | MVC ]

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

Контролер : Дякуємо, що чекали Перегляд , я поцікавився в моделі щодо вашого пошукового запиту. У ньому йдеться про те, що він знайшов список відповідних результатів і зберігав їх у змінній під назвою "searchResultsList" всередині свого примірника. Ви можете отримати його звідти. Також, будь ласка, прихойте панель прогресу зараз [ MVC ]

Перегляд : Дуже дякую презентатору [ MVP ]

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

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

• MVP = Model-View-Presenter

• MVC = Модель-перегляд-контролер

  1. Обидві моделі презентації. Вони розділяють залежності між Моделлю (об'єктами доменних об'єктів), екраном / веб-сторінкою (Перегляд) та тим, як повинен поводитися ваш інтерфейс користувача (Presenter / Controller)
  2. Вони досить схожі за концепцією, люди ініціалізують Presenter / Controller по-різному, залежно від смаку.
  3. Чудова стаття про відмінності тут . Найбільш помітним є те, що MVC-модель має модель оновлення подання.

Модель-перегляд-контролер

MVC - це шаблон для архітектури програмного забезпечення. Він розділяє логіку програми на три окремі частини, сприяючи модульності та простоті співпраці та повторного використання. Це також робить програми більш гнучкими та привітаннями до ітерацій. Він розділяє додаток на наступні компоненти:

• Моделі обробки даних та бізнес-логіки
• Контролери для управління користувальницьким інтерфейсом та додатком
• Перегляди для обробки об’єктів графічного інтерфейсу користувача та презентації

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

Model-View-Presenter

• модель являє собою дані , які будуть відображатися у вікні перегляду (призначеного для користувача інтерфейсу).
• вид являє собою інтерфейс , який відображає дані (модель) і команди маршрутів користувачів (події) до виступаючого діяти в відповідності з цими даними. Перегляд зазвичай має посилання на його ведучого.
• Presenter є «середнім людиною» ( в виконанні контролера в MVC) і мають посилання на обидва, вид і модель. Зверніть увагу, що слово "модель" вводить в оману. Це скоріше повинна бути ділова логіка, яка витягує або маніпулює Моделлю . Наприклад: Якщо у вас є база даних, що зберігає користувача в таблиці бази даних, і ваш перегляд хоче відобразити список користувачів, то презентатор матиме посилання на бізнес-логіку вашої бази даних (наприклад, DAO), звідки ведучий запитає список Користувачів.

Якщо ви хочете побачити зразок з простою реалізацією, будь ласка, перегляньте цю публікацію GitHub

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

Яка різниця між MVC та моделями MVP ?

MVC Шаблон

• Контролер базується на поведінці та може бути поділений у різних поглядах

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

MVP Pattern

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

• Легше перевірити блок, оскільки взаємодія з представленням здійснюється через інтерфейс

• Зазвичай перегляд карти ведучого один на один. Складні перегляди можуть мати кілька презентантів.

Також варто пам’ятати, що існують також різні типи MVP. Фоулер розбив схему на два - пасивний контролер і контролер.

Під час використання пасивного перегляду, ваш перегляд зазвичай реалізує тонкозернистий інтерфейс із властивостями, які відображаються більш-менш безпосередньо до віджету інтерфейсу користувача, що лежить нижче. Наприклад, у вас може бути ICustomerView із властивостями, такими як Ім'я та Адреса.

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

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

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

Другий аромат MVP - це контрольний контролер. У такому випадку у Вашого представлення може з’явитися властивість під назвою Клієнт, яка знову-таки пов'язана з віджетами інтерфейсу користувача. Вам не потрібно думати про синхронізацію та мікроуправління поданням, і контрольований контролер може заходити та допомагати, коли це потрібно, наприклад, із доповненою логікою взаємодії.

Третій "аромат" MVP (або хтось, можливо, назве це окремим малюнком) - це презентаційна модель (або іноді її називають Model-View-ViewModel). Порівняно з MVP ви "зливаєте" M і P в один клас. У вас є клієнтський об'єкт, до якого пов’язані дані віджетів вашого інтерфейсу, але ви також маєте додаткові поля, призначені для користувальницького інтерфейсу, наприклад "IsButtonEnabled" або "IsReadOnly" тощо.

Я вважаю, що найкращий ресурс, який я знайшов для архітектури інтерфейсу, - це серія публікацій блогу, яку зробив Джеремі Міллер в розділі Зміст власної CAB серії змісту . Він покрив усі аромати MVP та показав код C # для їх реалізації.

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

Кожен з них вирішує різні проблеми і навіть може бути об'єднаний разом, щоб мати щось подібне нижче

Тут також є повне порівняння MVC, MVP та MVVM

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

Існує дискусія тут про відмінності між MVC проти MVP.

Відмінність полягає в тому, що в додатку MVC традиційно представлення зображень і контролер взаємодіють з моделлю, але не один з одним.

Конструкції MVP надають презентатору доступ до моделі та взаємодіють із виглядом.

Сказавши це, ASP.NET MVC є за цими визначеннями рамкою MVP, оскільки Контролер отримує доступ до Моделі для заповнення Перегляду, який, мабуть, не має логіки (просто відображає змінні, надані Контролером).

Щоб отримати уявлення про відмінність ASP.NET MVC від MVP, ознайомтеся з цією презентацією MIX Скоттом Ханзельманом.

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

В архітектурному відношенні MVP - це підхід на базі контролера сторінок, де MVC - це підхід, заснований на передньому контролері. Це означає, що життєвий цикл сторінок веб-форми MVP просто покращується шляхом вилучення бізнес-логіки з коду позаду. Іншими словами, сторінка - це та, яка обслуговує http-запит. Іншими словами, MVP IMHO - це еволюційний тип розширення веб-форми. MVC з іншого боку повністю змінює гру, тому що запит перехоплюється класом контролера перед завантаженням сторінки, там виконується бізнес-логіка, а потім у кінцевому результаті обробка даних контролера щойно скидається на сторінку ("перегляд"). сенс, MVC виглядає (принаймні, на мене) на надзвичайний смак MVP, що підсилюється за допомогою двигуна маршрутизації

Обидва вони включають 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

У MVP подання черпає дані від презентатора, який черпає та готує / нормалізує дані з моделі, тоді як у MVC контролер черпає дані з моделі та встановлює, натискаючи в огляд.

У MVP ви можете мати один перегляд, який працює з декількома видами презентаторів, і один ведучий, що працює з різними кількома переглядами.

MVP зазвичай використовує якусь рамку прив'язки, таку як рамка зв'язування Microsoft WPF або різні рамки прив'язки для HTML5 та Java.

У цих рамках UI / HTML5 / XAML знає, яке властивість презентатора відображає кожен елемент інтерфейсу, тому, коли ви прив'язуєте подання до презентатора, представлення шукає властивості та знає, як отримувати з них дані та як встановити їх, коли користувач змінює значення в інтерфейсі користувача.

Так, якщо, наприклад, модель - це автомобіль, то презентатор - це якась презентація автомобіля, виставляє на вигляд властивості автомобіля (рік, виробник, сидіння тощо). Подання знає, що в текстовому полі під назвою "виробник автомобілів" потрібно відображати властивість Maker презентаторів.

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

Цей прив'язуючий фреймворк, якщо його зняти, це насправді контролер :-)

Отже, ви можете дивитися на MVP як на еволюцію MVC.

MVC чудовий, але проблема полягає в тому, що зазвичай його контролер на огляд. Контролер A знає, як встановити поля View A. Якщо зараз ви хочете, щоб View A відображав дані моделі B, вам потрібен Controller A, щоб знати модель B, або вам потрібен Controller A для отримання об'єкта з інтерфейсом - як MVP тільки без прив’язок, або вам потрібно переписати код набору інтерфейсу в Controller B.

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

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

З іншого боку, це правило великого масштабу може мати велику вагу, коли характеристики платформи сприяють певним відносинам між компонентами, як, наприклад, з Інтернетом, де MVC легше реалізувати, ніж MVP.

Я вважаю, що цей образ Ервіна Вандервалька (і супроводжуваної статті ) є найкращим поясненням MVC, MVP та MVVM, їх подібності та їх відмінностей. Стаття не відображається в результатах пошуку за запитами на «MVC, MVP і MVVM» , тому що назва статті не містить слова «MVC» і «MVP»; але я думаю, що це найкраще пояснення.

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

Існує багато версій MVC, ця відповідь стосується оригіналу MVC у Smalltalk. Якщо коротко, це так

Ця розмова droidcon NYC 2017 - чистий дизайн додатків з компонентами архітектури пояснює це

Є це приємне відео від дядька Боба, де він коротко пояснює MVC & MVP наприкінці.

IMO, MVP - це вдосконалена версія MVC, де ви в основному відокремлюєте питання про те, що ви збираєтеся показати (дані), від того, як ви збираєтеся показати (вид). Презентатор включає в себе ділову логіку вашого інтерфейсу, неявно нав'язує, які дані мають бути представлені, і дає вам список моделей, що мають неприємний вигляд. А коли настає час показу даних, ви просто підключите свій перегляд (ймовірно, включає той самий ідентифікатор) у свій адаптер і встановіть відповідні поля перегляду за допомогою тих моделей перегляду, в яких вводиться мінімальна кількість коду (просто за допомогою сетерів). Основна його перевага полягає в тому, що ви можете перевірити свою логіку бізнесу на інтерфейсі на багато / різних видах, як-от показ елементів у горизонтальному або вертикальному списку.

У MVC ми говоримо через інтерфейси (межі), щоб склеїти різні шари. Контролер є плагіном до нашої архітектури, але він не має такого обмеження, щоб накладати, що показувати. У цьому сенсі MVP - це різновид MVC з концепцією поглядів, що підключаються до контролера над адаптерами.

Я сподіваюся, що це допомагає краще.

Ви забули про Action-Domain-Responder ( ADR) ).

Як пояснено в деяких графіках вище, в MVC існує пряме відношення / зв'язок між Модель та Вид . Дія виконується на Контролері , який виконує дію на Моделі . Ця дія в моделі , буде викликати реакцію в View . View , постійно оновлюється , коли модель змінюється стан «s.

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

Оскільки ми використовуємо веб-рамки ( наприклад: Laravel ), які все ще використовують ті ж самі умови іменування ( model-view-controller ), ми схильні думати, що це повинен бути MVC, але насправді це щось інше.

Натомість подивіться на Action-Domain-Responder . У ADR контролер отримує дію , яка виконує операцію в моделі / домені . Поки що те саме. Різниця полягає в тому, що він збирає відповідь / дані операції та передає їх Відповідачеві ( наприклад:.view() ) Для надання. Коли запитується нова дія на тому ж компоненті, контролер знову викликається, і цикл повторюється. В ADR немає зв'язку між Модель / Домен та Переглядом (відповідь Reponser ).

Примітка. У Вікіпедії зазначено, що " Однак кожна АРС-дія представлена ​​окремими класами або закриттями ". Це не так обов'язково правда. Кілька дій може бути в одному контролері, і схема залишається однаковою.

mvc адр модель-перегляд-контролер дія-домен-відповідь

Найпростіша відповідь - те, як погляд взаємодіє з моделлю. У MVP подання оновлюється презентатором, який виступає посередником між поданням та моделлю. Презентатор приймає дані з подання, який отримує дані з моделі, а потім виконує будь-яку необхідну бізнес-логіку, а потім оновлює представлення даних. У MVC модель оновлює подання безпосередньо, а не повертається через контролер.

• У MVC, View має частину інтерфейсу, контролер є посередником між представленням та моделлю, а модель містить бізнес-логіку.
• У MVP, View містить як інтерфейс, так і реалізацію презентатора, оскільки тут презентатор - це просто інтерфейс, а модель - однакова, тобто містить бізнес-логіку.

MVP

MVP розшифровується як Model - View- Presenter. Це з'явилося на початку 2007 року, коли Microsoft представила програми Smart Client Windows.

Ведучий виконує роль наглядової ролі в MVP, яка пов'язує події та бізнес-логіку з моделями.

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

Перегляд є ініціатором для введення користувача, а потім делегує події Presenter, а ведучий обробляє прив'язки подій та отримує дані від моделей.

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

Мінуси: Бітова складна і більше роботи при здійсненні прив'язки подій

MVC

MVC розшифровується як Model-View-Controller. Контролер відповідає за створення моделей та надання представлень з прив'язними моделями.

Контролер є ініціатором і він вирішує, який вид подавати.

Плюси: наголос на принципі єдиної відповідальності Високий рівень перевірки

Мінуси: Іноді занадто велике навантаження для контролерів, якщо спробувати надати кілька переглядів в одному контролері.