12 подписчиков
🙂 Архитектурные паттерны (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
3 минуты
21 февраля