🙂 Архитектурные паттерны (MV(X)

Архитектурные паттерны — шаблоны для высокоуровневой организации системы.
Определяют основные компоненты системы, их взаимосвязи и взаимодействия

Паттерны MV(X) используются в
🟡мобильных и веб приложениях
🟡банкинге и финансовых системах, где важны четкая структура и гибкость
🟡в играх и графических интерфейсах (для отделения логики от UI и управления сложными связями)

MV(X) — семейство паттернов со схожей структурой
Разделяют приложения на основные компоненты:
⏩ Model — отвечает за данные, бизнес-логику, сервисы для работы с БД и сетью (например, класс в ООП, API, библиотека, микросервис и тд)
⏩ View — визуальное представление для пользователя, отображение данных из Model
❕эти компоненты выполняют одни и те же роли во всех паттернах MV(X)
⏩ Presenter / Controller / ViewModel - меняются в зависимости от паттерна

✅ Чем лучше разделение обязанностей между компонентами,
тем проще управлять проектом, добавлять и тестировать компоненты

Рассмотрим некоторые из них:

MVC (Model-View-Controller)

Controller: логика, которая связывает model и view
➡ направляет данные от пользователя к системе и наоборот
➡ напрямую обновляет view

Подходит для небольших / средних приложений
Чем проще Controller, тем лучше

Пример

В веб-приложении для управления библиотекой:
🟡Model: класс Book с полями title, author и методами для работы с книгами
🟡View: HTML-страница с формой для добавления книг и списком всех книг
🟡Controller: обработчик, который принимает POST-запросы на добавление книг и обновляет Model и View

Недостатки

✖ в больших приложениях Controller объемный ➡ сложнее поддержка кода
✖ View и Model разделены, но View и Controller тесно связаны ➡ тяжелее масштабировать каждый из этих компонентов
✖View и Controller тестировать сложно из-за тесной связи ➡ тестируется в основном Model


MVP (Model-View-Presenter)

Presenter: полностью управляет логикой view
➡ обрабатывает ввод
➡ взаимодействует с моделью
➡ обновляет view через интерфейс, не зависит от конкретной реализации view (как у controller)

Отличие от MVC: связь view и model идет через presenter, а не напрямую

Эффективен в приложениях с высокой нагрузкой на UI,
и где необходимы модульные тесты, т.к. Presenter можно тестировать

Пример

В Android-приложении для управления задачами:
🟡Model: класс task, представляет задачу с полями title, description и методами для изменения состояния
🟡View: UI для отображения списка задач и формы для добавления новой задачи
🟡Presenter: объект, который запрашивает список задач из Model и обновляет View при изменениях

Недостатки
✖ требует создания доп классов и интерфейсов ➡ может перегружать простые приложения


MVVM (Model-View-ViewModel)

View взаимодействует с ViewModel через привязку данных

ViewModel
🟡содержит свойства и команды, к которым привязывается View
🟡взаимодействует с Model для извлечения или обновления данных

Эффективен для приложений со сложными структурой данных и интерфейсом

Пример

В WPF-приложении для управления контактами:
⭕Model: класс Contact содержит информацию о контакте
⭕View: UI, показывает список контактов и формы для добавления/редактирования
⭕ViewModel: объект, который загружает данные из Model и обновляет View, а также обрабатывает команды от View

Недостатки
✖ сложно настроить привязку данных
✖ ViewModel может перегружаться лишней логикой


📎 Материалы
1. MVC
2. Достоинства использования MVC архитектуры в разработке клиент-серверного интернет-магазина
3. Что такое MVP архитектура
4. Реализация MVC паттерна на примере создания сайта-визитки на PHP
4. MVC против MVVM — разница между ними
5. Понимание различий: MVC и MVVM
6. Шпаргалка по MV-паттернам для проектирования веб-приложений
7. Архитектурные шаблоны: объяснение MVC, MVP и MVVM
8. Паттерны для новичков: MVC vs MVP vs MVVM


#архитектура #проектирование

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу