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

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

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

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

У вас есть слой с именем NetworkManager. NetworkManager является singerlton ко всем моим вызовам веб-службы.

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

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

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

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 выдает сетевой запрос с блоками. Значение вместо того, чтобы посредник перехватывал ответ перед MyUiViewController, просто позвольте MyUiViewController обрабатывать ответ с помощью блоков, поскольку он тот, который его выдает.

Pros:
Simple and quick to code
Easy to understand

Cons:
Coupling of network code inside your controllers

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

Ответы

Ответ 1

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

Вот что я делаю вообще,

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

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

Это может быть не лучшее решение, но, надеюсь, оно дает вам несколько указателей.

Ответ 2

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

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

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

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