Начнем с архитектурного паттерна VIPER. Как это работает? Как это реализовать? Давайте посмотрим на плюсы и минусы VIPER, а также сделаем некоторые теоретические выводы.
Если вы читаете это, это означает, что вы слышали об архитектуре VIPER и хотите понять , как она работает, минусы и плюсы VIPER и , для какого проекта требуется VIPER архитектура?
Я прочитал много статей о VIPER и не нашел объяснения того, как это должно работать, вместо объяснения какой-то конкретной реализации этой архитектуры. И поэтому я постараюсь прояснить, как это должно работать в целом.
Краткое объяснение каждого модуля:
- V (View / ViewController) - уровень для обработки взаимодействия с пользователем, создания макета.
- P (Presenter) - слой для преобразования и подготовки результатов бизнес-логики для отображения на слое V.
- I (Interactor) - слой для извлечения данных из сетевых сервисов, кеш. Основной слой бизнес-логики.
- R (Маршрутизатор) - слой логики навигации между другими модулями VIPER.
- 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:
- У каждого модуля есть серьезные обязанности. Один модуль легко заменить, не меняя другой. (принцип единой ответственности).
- Разрабатывать детали с несколькими разработчиками легко. (Если протоколы созданы - вы можете создать представление, которое будет взаимодействовать с абстрактным классом презентатора, а другой разработчик может создать презентатор для работы с абстрактным классом представления.
- Возможность тестирования (вы можете просто создать фиктивный класс интерактора с подтвержденным протоколом, и в тестовом режиме легко заменить реальный интерактор на фиктивный интерактор).
- Высокое обслуживание. Его легко поддерживать, потому что вы знаете, что и где оно должно быть. (Создание представления в представлении, форматирование текста в презентаторе, выборка данных в интеракторе, навигация между модулями в маршрутизаторе.
- Подходит для разработки через тестирование (TDD).
Минусы VIPER:
- Для VIPER вам нужно создать тонны шаблонного кода. Даже для простого экрана вам нужно создать как минимум 5 протоколов и 5 классов для согласованности кодовой базы.
- Это занимает много времени. (Вам нужно разделить один экран на абстракции и 5 модулей).
- Вам необходимо хорошее понимание ARC. потому что все модули имеют ссылки друг на друга, и вам нужно определить, какие ссылки должны быть слабыми.
- Плохой шаблон для постоянно меняющихся бизнес-целей и технических характеристик. (В этих условиях нужно менять много протоколов и классов).
Выводы:
В этой статье я попытался прояснить, что такое VIPER и как его модули взаимодействуют друг с другом. Итак, если вы хотите создать приложение в стиле TDD с определенными бизнес-целями. Если вам нужна простая тестируемость, ремонтопригодность и масштабируемость - VIPER - отличный выбор, чтобы разделить ваши модули на разные уровни и дать им абстракцию с серьезными обязанностями. VIPER - плохая идея для небольших стартапов без тестирования, с приоритетами и бизнес-целями, которые могут измениться в любую минуту.
Присоединяйтесь к моему блогу здесь!