Розділяй та володарюй: що таке патерни MVC і MVP, та як їх використовувати

Ми постійно використовуємо патерни програмування, не усвідомлюючи цього. Не замислюємось про те, чому на проєктах використовується саме така архітектура, чому структуру проєкту і навіть назви файлів використовують за саме такими загальноприйнятими канонами.

У цій статті я пропоную розібратись з одними з найуживаніших патернів — MVP та його пращуром MVC.

Патерн MVC

Почнемо в хронологічній послідовності з патерну MVC — він був створений в 1970-х роках і його метою було розбиття будь-якої програми, з якою взаємодіє користувач, на три логічні блоки:

1. Model — це бізнес-логіка додатку, в ньому відбуваються найважчі процеси (обробка, сортування, запис даних, звернення до бази даних, генерація вебсторінки тощо), і після виконаної події відправляє результат до View.
2. View — це інтерфейс, з яким взаємодіє користувач, візуальна частина (наприклад, сторінка сайту). Задача View — зчитати інформацію, введену користувачем, і передати її в конкретний метод або функцію контролера, а також зчитувати дії користувача (натискання кнопки або оновлення сторінки, що теж викликає метод або функцію з контролера).
   
3. Controller — приймає дані або подію від View і може діяти таким чином, наприклад:

• за допомогою виключень обирає конкретний метод Model, який треба викликати, спираючись на дані або подію від View;
• формує обʼєкт з отриманих параметрів, який передаємо до Model за допомогою метода, функції Model або створюємо http–запит до model.

Загалом у нас виходить циркуляційна взаємодія наших трьох модулів — тобто по колу:

Патерн MVP

Ми розглянули, з чого все почалось, і тепер готові піти далі.

Розглянемо патерн MVP — він відрізняється лише одним модулем, проте зовсім іншою взаємодією між ними.

Як ми бачимо, у нас тепер замість модуля Controller модуль Presenter, проте найголовніше — це те, як змінилась їхня взаємодія.

Тепер модулі View та Model спілкуються виключно через модуль Presenter, який є посередником: робить все, що робив Controller, звертається до Model, чекає на відповідь, отримує її і передає результат до View.

Переходимо до прикладів

Розглянемо все на прикладі простого проєкту, який має візуальну частину View-модель (index.html), Presenter з одного файлу та великий модуль Model.

Ви можете завантажити та протестувати проєкт з GitHub.

View:

В модулі View ми маємо лише розмітку, яка буде відображена у користувача, та імпортуємо потрібні нам скрипти включно і з презентером.

Presenter:

Файл presenter/index.js працює безпосередньо з html — змінює його, спираючись на дії користувача та дані, які отримує від запитів до моделі Model.

Файл presenter/requests.js має в собі функціонал запитів до Model за url–адресам і виконуються за допомогою axios.

Model:

Файл model/index.js — «серце» нашого сервера, тут ми запускаємо http-сервер та приймаємо запити по назначеним url-адресам.

Файл model/src/getAllMessages.js — одна з наших функцій, яка після виконання віддає відповідь до Presenter, який, в свою чергу, змінює View, який відмальовується за новими даними.

Замість висновку

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

Тож, завершуючи цю статтю, я хочу сказати: «Розділяйте та володарюйте».

Продуктивного вам кодування 😉