Начнем с архитектурного паттерна VIPER. Как это работает? Как это реализовать? Давайте посмотрим на плюсы и минусы VIPER, а также сделаем некоторые теоретические выводы.

Исходный пост

Если вы читаете это, это означает, что вы слышали об архитектуре VIPER и хотите понять , как она работает, минусы и плюсы VIPER и , для какого проекта требуется VIPER архитектура?

Я прочитал много статей о VIPER и не нашел объяснения того, как это должно работать, вместо объяснения какой-то конкретной реализации этой архитектуры. И поэтому я постараюсь прояснить, как это должно работать в целом.

Краткое объяснение каждого модуля:

  1. V (View / ViewController) - уровень для обработки взаимодействия с пользователем, создания макета.
  2. P (Presenter) - слой для преобразования и подготовки результатов бизнес-логики для отображения на слое V.
  3. I (Interactor) - слой для извлечения данных из сетевых сервисов, кеш. Основной слой бизнес-логики.
  4. R (Маршрутизатор) - слой логики навигации между другими модулями VIPER.
  5. E (Entity) - E (Entity) - Модели (локальные или доменные), актуальные данные.

Часть протоколов в VIPER - основная часть

Для большей тестируемости и поддержки нам необходимо создать абстрактные протокольные соединения между модулями. Здесь это срочно.

На изображении выше представлено неправильное соединение между модулем, потому что эти 2 модуля должны знать о реальных классах презентатора и представления. Поэтому, если все наши модули VIPER будут подключены таким образом, будет сложно заменить некоторые модули на другом модуле без огромных перестроек. Кроме того, будет сложно изменить, например, ведущего без изменения представления и так далее. Все эти проблемы указывают на нарушение концепции чистой архитектуры.

Протоколы могут помочь нам в создании этой абстракции. Создадим 2 протокола для ведущего и просмотра.

Теперь мы можем создать 2 наших класса для соответствия этим протоколам.

Итак, какие проблемы здесь решаются? Сначала - мы можем создать любой класс, например, SecondViewController и после согласования с ним FirstViewProtocol - можно будет использовать этот класс вместо нашего FirtViewController . Это возможно, потому что наш докладчик смотрит на представление, как в FirstViewProtocol, это просто абстракция, и любой класс может соответствовать этому протоколу и заменять старое представление. Все, что другой класс может знать о FirtViewProtocol, что это должен быть класс и у него должен быть метод setTextToLabel, и все. Все реализации могут отличаться в разных классах, соответствующих этому протоколу. Поэтому, если вам нужно заменить старое представление каким-либо новым, вы можете просто согласовать FirstViewProtocol со своим новым ViewController, и это не повлияет на другие части VIPER (ведущий , интерактор, роутер и т. д.).

Итак, для VIPER по умолчанию нам просто нужно создать 5 протоколов:

1 - для связи между представителем и докладчиком.

2 - для связи между ведущим и представлением.

3 - для связи между ведущим и маршрутизатором.

4 - для связи между ведущим и взаимодействующим.

5 - для связи между интерактором и докладчиком.

Таким образом, каждый протокол содержит только минимум свойств и методов, чтобы быть конкретным модулем. Например, протоколу FirstViewProtocol нужны только метод presenter: FirstPresenterProtocol и setTextLabel. Таким образом, любой класс может соответствовать этому протоколу и заменить старое представление.

Плюсы VIPER:

  1. У каждого модуля есть серьезные обязанности. Один модуль легко заменить, не меняя другой. (принцип единой ответственности).
  2. Разрабатывать детали с несколькими разработчиками легко. (Если протоколы созданы - вы можете создать представление, которое будет взаимодействовать с абстрактным классом презентатора, а другой разработчик может создать презентатор для работы с абстрактным классом представления.
  3. Возможность тестирования (вы можете просто создать фиктивный класс интерактора с подтвержденным протоколом, и в тестовом режиме легко заменить реальный интерактор на фиктивный интерактор).
  4. Высокое обслуживание. Его легко поддерживать, потому что вы знаете, что и где оно должно быть. (Создание представления в представлении, форматирование текста в презентаторе, выборка данных в интеракторе, навигация между модулями в маршрутизаторе.
  5. Подходит для разработки через тестирование (TDD).

Минусы VIPER:

  1. Для VIPER вам нужно создать тонны шаблонного кода. Даже для простого экрана вам нужно создать как минимум 5 протоколов и 5 классов для согласованности кодовой базы.
  2. Это занимает много времени. (Вам нужно разделить один экран на абстракции и 5 модулей).
  3. Вам необходимо хорошее понимание ARC. потому что все модули имеют ссылки друг на друга, и вам нужно определить, какие ссылки должны быть слабыми.
  4. Плохой шаблон для постоянно меняющихся бизнес-целей и технических характеристик. (В этих условиях нужно менять много протоколов и классов).

Выводы:

В этой статье я попытался прояснить, что такое VIPER и как его модули взаимодействуют друг с другом. Итак, если вы хотите создать приложение в стиле TDD с определенными бизнес-целями. Если вам нужна простая тестируемость, ремонтопригодность и масштабируемость - VIPER - отличный выбор, чтобы разделить ваши модули на разные уровни и дать им абстракцию с серьезными обязанностями. VIPER - плохая идея для небольших стартапов без тестирования, с приоритетами и бизнес-целями, которые могут измениться в любую минуту.

Присоединяйтесь к моему блогу здесь!