Які поліпшення MVP над MVC?

Я три дні читав про моделі Model-View-Controller (MVC) та Model-View-Presenter (MVP) . І є одне питання, яке мене дуже турбує. Чому розробники програмного забезпечення винайшли MVP, коли вже був MVC?

З якими проблемами вони зіткнулися, що MVC не вирішив (або вирішив погано), але MVP може вирішити? Які проблеми призначений вирішити MVP?

Я прочитав багато статей про історію та пояснення MVP або про відмінності між MVC та MVP, але жодна не мала чіткої відповіді на мої запитання.

В одній із статей, яку я прочитав, було сказано:

Тепер перегляньте Model View Presenter, який був відповіддю на неадекватність шаблону MVC при застосуванні до сучасних графічних інтерфейсів на основі компонентів. У сучасних системах GUI компоненти GUI самі обробляють введення користувача, наприклад, переміщення та натискання миші, а не якийсь центральний контролер.

Отже, я не можу зрозуміти, але чи може це бути інакше, таким чином, щоб компоненти GUI не обробляли користувальницькі дані самостійно? А що саме означає "впоратися самим"?

— Віктор
джерело

Дублікат stackoverflow.com/questions/2056 / ...

— qwerty_so

Я думаю, що це просто «Нова одяг Імператора», нове мовлення від Міккісофт.

— qwerty_so

Вікторе, у вас є конкретне питання, окрім "чому існують дві різні схеми?" Існує дві різні закономірності, оскільки вони вирішують одну і ту ж проблему двома дещо різними способами. Якщо це допомагає, модель і вид по суті однакові в обох моделях. Зосередьтеся на відмінностях між контролером та ведучим. Довідку можна знайти тут: linkedin.com/pulse/…

— Роберт Харві

"Я читав три дні про схеми MVC та MVP." Yikes. Я пропоную вам зайнятися розслаблюючою гарячою ванною або пропустити камені через заповнений качкою ставок чи щось таке. Таке читання може, за відсутності будь-якого практичного застосування, справді розтопити ваш мозок!

— користувач1172763

Спосіб отримання відповіді, яку ви хочете, - це побудова чогось за допомогою цих шаблонів. Тоді ви будете освічені.

— Роберт Харві

Відповіді:

MVC концептуально елегантний:

введення користувача обробляється контролером
контролер оновлює модель
модель оновлює інтерфейс перегляду / користувача

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

Однак: Потік даних та подій у MVC є круговим. А представлення часто містить значну логіку (як обробники подій для дій користувача). Разом ці властивості ускладнюють перевірку системи і важко підтримувати.

Архітектура MVP замінює контролер на презентатор, який опосередковує перегляд і модель. Це лінеаризує систему:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Це має такі переваги:

Логіку (наприклад, обробники подій та стан користувальницького інтерфейсу) можна перемістити з подання на презентатора.
Користувацький інтерфейс може бути перевірений одиницею з точки зору презентатора, оскільки він описує стан інтерфейсу користувача. Всередині тестування блоку ми заміняємо подання тестовим драйвером, який здійснює дзвінки до ведучого.
Оскільки інтерфейс користувача ізольований від логіки програми, обидва можуть бути розроблені незалежно.

Але є й деякі недоліки цього підходу:

Це вимагає більше зусиль.
Ведучий може легко мутувати в неможливий "клас богів".
У додатку немає однієї осі MVP, а декілька осей: по одному для кожного екрана / вікна / панелі в інтерфейсі користувача. Це може або спростити вашу архітектуру, або жахливо ускладнити її.

— амон
джерело

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

— Роберт Харві

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

— Віктор

@Victor Не існує найкращої моделі, але компроміси різні. MVC може відповідати складним вимогам. Що стосується архітектури, MVP застосовує відносини 1: 1 між переглядами та презентаторами: у кожного перегляду є власний ведучий, кожен ведучий підключений до одного виду. У MVC існує зв'язок n: m: Один вид може надсилати введення користувача на кілька різних контролерів, а один контролер може отримувати введення з багатьох переглядів. Це гнучкіше, але й більш хаотично - у MVC немає чіткої “осі”.

— амон

@Victor Я не маю великого досвіду роботи з графічними інтерфейсами, тому, мабуть, багато чого я не згадував. Останній графічний інтерфейс, який я зробив, був абсолютним безладом, оскільки в той момент я не знав про MVP - лінеаризований потік даних та контролю був би величезним поліпшенням.

— амон

@RobertHarvey Я б заперечував, що те, що Інтернет називає "MVC", ніколи насправді не було "MVC" за початковим визначенням. Той, хто захопив абревіатуру, повинен вдарити головою в голову, щоб вибрати термін, що заблокував, і заплутати всіх.

— jpmc26

У MVP презентатор замінює контролер MVC. Різниця між ними полягає в тому, що ведучий безпосередньо маніпулює видом. Він розроблений для фреймворків інтерфейсу, які в основному керуються подіями (як Windows Forms), без важкої підтримки для багатих прив'язок даних, які б надавали шаблону MVVM (наприклад, WPF). Інакше багато логіки управління станом перегляду та оновлення моделі резервної копії лежить у самому поданні.

— Майкл Браун
джерело