1 VIPER чеклист
Jesus edited this page 2024-08-22 17:14:44 +07:00
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Чеклист для VIPER:

1. View (ViewController)

  • Не содержит бизнес-логики. ViewController отвечает только за отображение данных и управление пользовательским интерфейсом.
  • Работает только с ViewModel. Данные передаются в виде ViewModel, подготовленной Presenter.
  • Инициирует запросы напрямую в Interactor. ViewController передает запросы на действия пользователя напрямую в Interactor.
  • Получает данные от Presenter. После обработки запроса Interactor передает данные в Presenter, а Presenter передает их обратно в ViewController.
  • Соблюдает принципы Single Responsibility. ViewController отвечает только за отображение данных и взаимодействие с пользователем.

2. Interactor

  • Содержит бизнес-логику. Interactor обрабатывает запросы, выполняет бизнес-логику и взаимодействует с Entity.
  • Получает запросы от View напрямую. Все запросы на обработку данных поступают в Interactor напрямую от ViewController.
  • Обрабатывает данные и передает результаты в Presenter. После обработки данных Interactor передает результаты в Presenter для подготовки данных к отображению.
  • Не имеет прямого доступа к UI. Interactor взаимодействует с Presenter и Entity, не имея доступа к View.
  • Асинхронные операции. Любые длительные операции (например, сетевые запросы, работа с базой данных) должны выполняться в Interactor.

3. Presenter

  • Получает данные от Interactor. После выполнения бизнес-логики Interactor передает данные Presenter.
  • Подготавливает данные для View. Преобразует данные в ViewModel для отображения в View.
  • Передает данные обратно в View. После подготовки ViewModel данные передаются в View для отображения.
  • Не содержит бизнес-логики. Presenter только управляет потоком данных и подготовкой ViewModel.

4. Entity

  • Содержит только данные и доменную логику. Entity представляет собой объекты данных, которые могут включать методы для работы с этими данными.
  • Не содержит бизнес-логики. Entity может включать простую доменную логику, но вся сложная бизнес-логика должна находиться в Interactor.
  • Повторно используется в Interactor. Entity может использоваться в нескольких Interactor'ах, если это необходимо.

5. Router

  • Отвечает за навигацию. Router отвечает за переходы между экранами и сборку модулей.
  • Не содержит бизнес-логики или UI-кода. Router только управляет навигацией и не вмешивается в обработку данных.
  • Использует фабрику для создания модулей. Router должен включать фабрику для создания View, Interactor, Presenter и их связывания.
  • Передает данные между модулями. При переходе на другой экран Router может передавать данные между модулями.
  • Изолирует навигацию от View и Presenter. View и Presenter не должны напрямую управлять навигацией.

6. Общие принципы

  • Четкое разделение ответственности. Каждый компонент VIPER должен четко выполнять свою роль.
  • Минимизация зависимостей. Компоненты должны быть слабо связаны и взаимодействовать через протоколы.
  • Использование протоколов для общения. Для общения между компонентами всегда должны использоваться протоколы.
  • Тестируемость. Каждый компонент должен быть легко тестируемым в изоляции от других.
  • Правильное именование. Имена компонентов и протоколов должны ясно отражать их роль и назначение.

7. Архитектурные решения

  • Поддержка модульности. Каждый экран или функциональность должна быть отдельным модулем VIPER.
  • Использование Dependency Injection. Для внедрения зависимостей рекомендуется использовать DI.
  • Сохранение чистоты слоев. Убедитесь, что бизнес-логика, UI-код и навигация четко разделены по слоям.
  • Соблюдение односторонних связей. Поток данных должен быть направлен только в одну сторону: View → Interactor → Presenter → View.

8. Рефакторинг и поддержка

  • Регулярные ревью кода. Проводите регулярные ревью кода для поддержания чистоты архитектуры.
  • Обновление документации. Документируйте каждый компонент и его взаимодействие с другими.
  • Рефакторинг при необходимости. Не бойтесь рефакторинга при обнаружении нарушений архитектурных принципов.