Извините за задержку с этим, но после прочтения статей я понял, что текущий способ настройки приложения NasaAPOD не очень интересен для реализации VIPER. В приложении должно было быть больше взаимодействий, поэтому я вернулся к MVC, MVVM и MVP, чтобы реализовать одно и то же по всем направлениям. Что я сделал, так это добавил функцию «избранное», которая просто перемещает избранное в верхнюю часть таблицы (на самом деле ничего не сохраняет). Так что хотя бы MVP и VIPER теперь немного интереснее. Единственное, в чем я не был уверен, так это в том, как настроить презентатора/интерактеров для ячеек. Казалось, что в нем должен быть компонент докладчика/интерактора, поскольку он также обрабатывает кэширование изображения. Но я не мог придумать, как удостовериться, что я не создаю тонны или, возможно, не сливаю их.

Учебник auth0.com определенно очень помог, поэтому мое приложение VIPER во многом основано на нем. Одна вещь, которую я нашел довольно странной, но, основываясь на предыдущей работе, является нормальной: когда пользователь нажимает на что-то, он проходит через докладчик только для немедленного возврата к представлению. Например, пользователь нажимает значок информации, вид сообщает докладчику, что пользователь нажал, ведущий возвращается к просмотру, сообщая о том, что произошло касание, и представляет детали.

Сайт auth0 также посоветовал вам не создавать все свои файлы вручную (я так и сделал 🙃), они предложили использовать инструменты для создания файлов для вас. Поскольку я решил создавать все свои файлы вручную, мне определенно было трудно продумать все взаимодействия и протоколы, необходимые для каждого файла для моего приложения. Настолько, что я его вытащил.

Одна вещь, которую я сделал немного по-другому, заключалась в том, как приложение устанавливает докладчиков и интеракторов. Сайт auth0 сделал эти переменные общедоступными, но я хотел, чтобы все было приватно. Поэтому я добавил функции attachView(viewInteractor:), attachInteractor(interactor:) и attachPresenter(presenter:). Готовое приложение вы можете увидеть ниже.



ashleyng/ArchitectureDesignPatterns
Внесите свой вклад в разработку ArchitectureDesignPatterns, создав учетную запись на GitHub.github.com



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



Сравнение архитектур MVVM и Viper: когда использовать одну или другую
TL;DR: Хорошо спроектированная архитектура важна для поддержания проекта в долгосрочной перспективе. В этой статье…auth0.com



  • Вид, Interactor, Presenter, Entity и Router
  • Вид — уровень интерфейса (файлы UIKit). Представления отвечают за отображение того, о чем их просит ведущий, и за передачу пользовательского ввода обратно докладчику.
  • Interactor — отвечает за выборку данных из уровня модели (с использованием сети или локальной базы данных), и его реализация полностью независима от пользовательского интерфейса.
  • Presenter — просмотрите логику для форматирования отображаемых данных. Это часть работы, выполняемой ViewModel в MVVM. Presenter получает данные от интерактора, создает модель представления и переносит ее в представление. Также реагирует на пользовательский ввод, запрашивая дополнительные данные или отправляя их обратно в интерактор.
  • Сущность — часть обязанностей уровня модели. Обычные объекты данных без бизнес-логики. Управляется интерактором.
  • Маршрутизатор — логика навигации приложения. Пример: если вам нужно повторно использовать одни и те же представления iPhone в приложении для iPad, единственное, что может измениться, — это способ представления представлений. Это позволяет вашим другим слоям оставаться нетронутыми.

Пример приложения

Вид

  • Он пассивен; только передает события интерфейса ведущему и обновляет себя при уведомлении ведущего

Интерактор

  • Запрашивает только localDataManager (протокол) для данных. Ему все равно, что используется как локальное хранилище, Core Data, Realm или что-то еще.
  • Interactor уведомляет ведущего и отправляет то, что он получил. Приведенное решение заключается в том, что он возвращает пустой массив, но другой вариант — распространить ошибку и позволить докладчику. Затем ведущий будет нести ответственность за форматирование объекта ошибки для представления.

Ведущий

  • Как вы могли заметить, выступающие могут стать большими. Когда это происходит, интересно разделить его на две части: презентатор, который будет только получать данные и форматировать их обратно в представление; и обработчик событий, который будет реагировать на события интерфейса.

Маршрутизатор

  • Ответственность за навигацию между модулями разделяется между докладчиком и каркасом. Ведущий получает пользовательский ввод и знает, когда нужно перемещаться, а каркас знает, как перемещаться.
  • Так как за создание модуля отвечает вайрфрейм, то здесь удобно задавать все зависимости. При представлении другого модуля каркас получает объект, который его представит, и запрашивает другой каркас для представленного модуля.


Архитектура приложений для iOS с помощью VIPER · objc.io
objc.io публикует книги о передовых методах и методах разработки для iOS и OS Xwww.objc.io



  • Отдельные слои VIPER помогают решить эту проблему, предоставляя четкие места для логики приложения и кода, связанного с навигацией.
  • Приложения часто реализуются как набор вариантов использования. Варианты использования также известны как критерии приемлемости или поведения и описывают, для чего предназначено приложение. Вариант использования — это уровень приложения, отвечающий за бизнес-логику. Сценарии использования должны быть независимы от их реализации пользовательского интерфейса. Они также должны быть небольшими и четко очерченными.

Интерактор

  • Он содержит бизнес-логику для управления объектами модели (сущностями) для выполнения конкретной задачи.
  • Обычно Interactor должен инициировать сетевую операцию, но он не будет обрабатывать сетевой код напрямую. Он запросит зависимость, например сетевой менеджер или клиент API.

Организация

  • Сущности — это объекты модели, которыми манипулирует Interactor. Объектами управляет только Interactor. Interactor никогда не передает объекты на уровень представления (т.е. Presenter).

Маршрутизация

  • Поскольку Presenter содержит логику для реагирования на пользовательский ввод, именно Presenter знает, когда перейти к другому экрану и к какому экрану перейти. Между тем каркас умеет ориентироваться. Таким образом, Presenter будет использовать каркас для навигации. Вместе они описывают маршрут от одного экрана к другому.