Ми постійно використовуємо патерни програмування, не усвідомлюючи цього. Не замислюємось про те, чому на проєктах використовується саме така архітектура, чому структуру проєкту і навіть назви файлів використовують за саме такими загальноприйнятими канонами.
У цій статті я пропоную розібратись з одними з найуживаніших патернів — MVP та його пращуром MVC.
Патерн MVC
Почнемо в хронологічній послідовності з патерну MVC — він був створений в 1970-х роках і його метою було розбиття будь-якої програми, з якою взаємодіє користувач, на три логічні блоки:
- Model — це бізнес-логіка додатку, в ньому відбуваються найважчі процеси (обробка, сортування, запис даних, звернення до бази даних, генерація вебсторінки тощо), і після виконаної події відправляє результат до View.
- View — це інтерфейс, з яким взаємодіє користувач, візуальна частина (наприклад, сторінка сайту). Задача View — зчитати інформацію, введену користувачем, і передати її в конкретний метод або функцію контролера, а також зчитувати дії користувача (натискання кнопки або оновлення сторінки, що теж викликає метод або функцію з контролера).
- 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 на новий код за сучасними стандартами або ж взагалі на інший сервер — і це зовсім не вплине на роботу інших модулів.
Тож, завершуючи цю статтю, я хочу сказати: «Розділяйте та володарюйте».
Продуктивного вам кодування 😉
Favbet Tech – це ІТ-компанія зі 100% українською ДНК, що створює досконалі сервіси для iGaming і Betting з використанням передових технологій та надає доступ до них. Favbet Tech розробляє інноваційне програмне забезпечення через складну багатокомпонентну платформу, яка здатна витримувати величезні навантаження та створювати унікальний досвід для гравців.
Цей матеріал – не редакційний, це – особиста думка його автора. Редакція може не поділяти цю думку.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: