Перейти к основному содержимому

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

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

Рассмотрим паттерны MV(X) и VIPER.
Используются в:

  • мобильных и веб-приложениях
  • банкинге и финансовых системах, где важны четкая структура и гибкость
  • играх и графических интерфейсах (для отделения логики от 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, isbn и методами для работы с книгами
  • 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 может перегружаться лишней логикой

MVVM-C (Model-View-ViewModel-Coordinator)​

Три первых компонента как у MVVM.
Coordinator отвечает за маршрутизацию между экранами приложения.

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

Пример
В iOS-приложении для новостей:

  • Model: класс Article содержит информацию о статье
  • View: интерфейс для отображения списка статей
  • ViewModel: подготавливает данные из Model и передает их в View
  • Coordinator: управляет переходом к экрану деталей статьи при нажатии на заголовок

Недостатки:

  • Усложняет архитектуру и требует доп компонентов

VIPER (View-Interactor-Presenter-Entity-Router)

Компоненты:

  • View — визуальное представление (как и везде)
  • Interactor содержит бизнес-логику, связанную с данными (Entities): например, создание новых видов сущностей или получение их с сервера
  • Presenter содержит бизнес-логику, связанную с UI, вызывает методы в Interactor
  • Entities — простые объекты данных, не являются слоем доступа к данным (это ответственность слоя Interactor)
  • Router - несет ответственность за переходы между VIPER-модулями

Применим:

  • Для больших и сложных приложений
  • Когда требуется масштабируемость, тестируемость (лучшее распределение — лучшая тестируемость)

Пример
В iOS-приложении для покупок:

  • View: интерфейс для отображения списка товаров
  • Interactor: логика получения товаров из API и обработки данных
  • Presenter: подготавливает данные и передает их в View для отображения
  • Entity: структуры данных о товарах
  • Router: управляет переходом к экрану деталей товара

Недостатки:

  • Высокая сложность самой архитектуры (при этом отличное распределение обязанностей)

Отличие VIPER от MV(X)

  • Логика из Model (взаимодействие данных) смещается в Interactor
  • Есть Entities — структуры данных, которые ничего не делают
  • Из Controller, Presenter, ViewModel обязанности представления UI переместились в Presenter, но без возможности изменения данных
  • VIPER — шаблон, который пробует решить проблему навигации — через Router

Материалы

Статьи​

  1. MVC
  2. Достоинства использования MVC архитектуры в разработке клиент-серверного интернет-магазина
  3. Model-View-Controller в .Net
  4. Реализация MVC паттерна на примере создания сайта-визитки на PHP
  5. MVC против MVVM — разница между ними
  6. Понимание различий: MVC и MVVM
  7. Как перестать использовать MVVM
  8. Почему MVx архитектуры всегда получаются плохо
  9. Шпаргалка по MV-паттернам для проектирования веб-приложений
  10. Архитектурные шаблоны: объяснение MVC, MVP и MVVM
  11. Паттерны для новичков: MVC vs MVP vs MVVM
  12. Паттерны разработки: MVC vs MVP vs MVVM vs MVI
  13. Википедия о MVP
  14. Что такое MVP архитектура
  15. MVVM: проектирование приложений для Windows
  16. Архитектура VIPER: простыми словами
  17. Введение в VIPER
  18. Понимаем архитектуру VIPER
  19. Почему VIPER это плохой выбор для вашего следующего приложения
  20. Разбор архитектуры VIPER на примере небольшого iOS приложения на Swift 4

Посты из нашего канала​

  1. Паттерны проектирования и архитектурные паттерны
  2. GRASP: краткий обзор
  3. Паттерны асинхрона: Request-Reply, Publish-Subscribe, Point-to-Point
  4. Распределенные системы: архитектурные паттерны и стили
  5. Паттерны CQRS и Event Sourcing в микросервисной архитектуре
  6. Паттерны API Gateway и BFF

Видео​

  1. Model View Presenter, MVP, Модель Вид Представитель, С#, Unity
  2. MVC, MVVM Архитектура. Наглядная теория и примеры
  3. Что такое архитектура приложения. Паттерны MVC, MVP, MVVM.
  4. Архитектура. M(VC, VP, VVM) [RU] / Мобильный разработчик
  5. Что такое MVC за 4 минуты
  6. MVVM. Model-View-ViewModel шаблоны проектирования архитектуры приложения
  7. Дмитрий Михайлов «VIPER»
  8. Архитектура приложения, почему VIPER