Ответственность за быструю обработку ошибок с помощью VIPER и сервисов

#ios #swift #viper #viper-architecture

#iOS #swift #viper-архитектура

Вопрос:

Я нашел эту статью о том, как создать модуль viper. Для меня все еще остается под вопросом то, что я не знаю, какой элемент отвечает за обработку ответа или должна ли эта обработка частично обрабатываться 2 или более элементами V, I, P, E или R.

Итак, у нас есть следующая очередь, обычно в цикле VIPER

  1. ViewController запрашивает presenter для выполнения чего-либо в viewDidLoad, например, для загрузки чего-либо в фоновом режиме.
  2. Ведущий запрашивает функцию взаимодействия для выполнения некоторой дополнительной работы, такой как вызов некоторых служб
  3. Службы выполняют некоторый запрос NSURLSession и перезванивают к Interactor.

Это очевидная очередь, как вы можете видеть, если вы знакомы с VIPER, я пропустил некоторые протоколы и расширения элементов VIPER.

В приведенной выше ссылке у нас есть функция:

 static func getPosts(completionHandler: @escaping ([Post]?, Error?) -> Void) {
 

как вы можете видеть, он не возвращает необработанный ответ по завершении, а скорее выполняет некоторые проверки на наличие данных и ошибок.

И мой вопрос: это законно? Я думаю, что существует нарушение единой ответственности или, по крайней мере, нарушение VIPER.

Как лучше всего проверять ошибки, лучше ли вводить какой-либо конструктор данных в service func, где парень получает сообщение.

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

Ответ №1:

Для меня все еще остается под вопросом то, что я не знаю, какой элемент отвечает за обработку ответа.

  1. VIPER сообщает только о необходимых деталях для одного модуля. Это не заставляет вас Interactor напрямую зависеть Storage от / Cache / NetworkClient . У вас также могут быть дополнительные объекты, такие как репозиторий, чтобы ваши зависимости стали похожими Interactor на -> Repository -> NetworkClient .
  2. Это совершенно нормально, что NetworkClient может передавать либо данные, либо ошибку. Однако Result<[Post], NetworkClientError> в этом случае было бы более быстрым.

В этом случае все в порядке, что Interactor обрабатывает ошибки, связанные с сетью. Например. Interactor может решить сделать несколько попыток повторить попытку, если ошибка связана с подключением к Интернету.

Комментарии:

1. да, это был главный вопрос для меня, спасибо за реальный пример с попытками повторить попытку! Я предполагал сохранить такую логику, например, в сервисе или в presenter.

2. Круто! Если вы считаете, что ответ решил вашу проблему, пожалуйста, отметьте его как «принятый». 🙂