iPhone - Архитектура для viewController и сетевых запросов

Question

Итак, у меня есть 2 типа данных, некоторые должны быть сохранены, а некоторые нет.

Я думаю о том, куда поместить весь мой связанный с сетью код, внутри моих UIViewControllers, откуда все сетевые запросы начинаются, или на другом уровне.

Я имел в виду следующее:

Есть слой под названием NetworkManager. NetworkManager является singerlton для всех моих вызовов веб-службы.

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

Но есть много других типов запросов. Например: запрос входа в систему, запрос информации о пользователе, friendsNearBy и т. Д.… Некоторые не обязательно должны быть постоянными в моей базе данных, а некоторые не соответствуют архитектуре FRC.

Для такого типа запросов, насколько я вижу, есть 2 способа его обработки:

1. Есть еще один слой, который разделяет ViewControllers и NetworkManager. Давайте назовем это Mediator. Mediator получает запрос словаря (JSON) от networkManager, решает в соответствии с логикой приложения, нужно ли с ним что-то еще делать, а затем публикует уведомление с соответствующим именем и данными. Если посредник сохраняет UIViewController, который отправил запрос, он может делегировать ответ непосредственно ему вместо публикации уведомления.

Поток будет таким:

MyUiViewController - > Mediator -> NetworkManger->Mediator-> PostNotification (or directly back to MyUiViewController)

Pros:
Decoupling
Nice structure and separation of concerns

Cons:
Harder to code
Sometimes harder to understand and debug.

2. Не имея этой трехуровневой архитектуры, но вместо этого имея MyUiViewControllers, выдает сетевой запрос с блоками. То есть вместо того, чтобы Mediator перехватывал ответ перед MyUiViewController, просто позвольте MyUiViewController обрабатывать ответ с использованием блоков, поскольку он является тем, который его выдает.

Pros:
Simple and quick to code
Easy to understand

Cons:
Coupling of network code inside your controllers

Я надеялся получить предложения и комментарии о том, что лучше из опыта людей или другого / лучшего способа сделать это.

Answer 1

Я рекомендую вариант 2 с небольшим количеством того, что вы перечислили для варианта 1. В моих приложениях у меня, как правило, есть два различных режима работы, которые работают одновременно.

Автоматическая загрузка: Основные данные приложения загружаются и сохраняются непосредственно в базе данных. Это инициируется каждый раз, когда приложение становится активным. Когда каждый запрос завершается, NSNotification отправляется для любых видимых контроллеров представления, которые могут нуждаться в информации о новых данных.

Например, если я сохраню данные игрока, я отправлю уведомление типа «PlayerDataUpdated». Когда контроллер представления виден, он слушает уведомления. Когда он не виден, он не слушает уведомления, так как любые изменения в базе данных будут обнаружены во время viewWillAppear.

Пользовательские загрузки: Для инициируемых пользователем сетевых запросов, таких как pull to refresh, следует вызвать соответствующий метод в NetworkManager из контроллера представления, которому требуются обновленные данные.

Answer 2

У вас уже есть лучший метод?

Вот что я обычно делаю,

Имейте NetworkManager, который не является Singleton. Определите протокол с помощью метода OnSuccess, OnError. Реализуйте это в вашем ViewController, который инициирует сетевое соединение. Установите делегата в NetworkManager и позвольте делегату быть вызванным при выполнении асинхронного запроса.

Используйте делегаты вместо блоков, поскольку их легко обслуживать.

Возможно, это не лучшее решение, но, надеюсь, оно даст вам несколько советов.