iPhone - Arquitectura para viewController y solicitudes de red

Question

Por lo tanto, tengo 2 tipos de datos, algunos necesitan persistir y otros no.

Estoy pensando en dónde poner todo mi código relacionado con la red, dentro de mis UIViewControllers, donde comienza toda la solicitud de red, o en otra capa.

Lo que tenía en mente es la siguiente:

tienen una capa llamada NetworkManager. NetworkManager es cantante en todas mis llamadas a servicios web.

Para los datos que deben ser persistentes y pueden presentarse en una lista, el administrador de red emite la solicitud, guarda la respuesta en mi base de datos local y escucha mis datos UIViewController usando FetchResultsController.

Pero hay muchos otros tipos de solicitudes. Por ejemplo: solicitud de inicio de sesión, solicitud de información de usuario, friendsNearBy, etc. ... algunos no tienen que ser persistentes en mi base de datos, y algunos no se ajustan a la arquitectura de FRC.

Para este tipo de solicitud, por lo que veo, hay 2 maneras de manejar que:

1. tener otra capa que separa entre las ViewControllers y el NetworkManager. Llamémoslo Mediator. El Mediator obtiene la solicitud de diccionario (JSON) de networkManager, decide de acuerdo con la lógica de la aplicación si hay algo más que hacer con ella y luego publica una notificación con el nombre y los datos apropiados. Si el mediador guarda el UIViewController que emitió la solicitud, puede delegar la respuesta directamente a él en lugar de publicar una notificación.

El flujo sería así:

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. no tener esta arquitectura en capas 3, pero en lugar de tener MyUiViewControllers, emitir una solicitud de red con bloques. Significando que en lugar de que el Mediator intercepte la respuesta antes de MyUiViewController, simplemente deja que MyUiViewController maneje la respuesta usando bloques ya que él es el que lo emite.

Pros: 
Simple and quick to code 
Easy to understand 

Cons: 
Coupling of network code inside your controllers 

Tenía la esperanza de obtener sugerencias y comentarios acerca de qué es lo mejor de la experiencia de las personas, o de otra manera mejor de hacer esto /.

Answer 1

¿Ya tienes cuál es el mejor método?

Esto es lo que hago en general,

Tener un NetworkManager que no es Singleton. Defina un protocolo con el método OnSuccess, OnError. Implemente esto en su ViewController que inicia la conexión de red. Establezca el delegado en NetworkManager y permita que se llame al delegado cuando se ejecute la solicitud asincrónica.

Use los delegados en lugar de bloques ya que es fácil de mantener.

Puede que esta no sea la mejor solución, pero con suerte le da algunos consejos.

Answer 2

Recomiendo la opción 2 con un poco de lo que enumeró para la opción 1.En mis aplicaciones, tiendo a tener dos modos distintos de operación que operan al mismo tiempo.

Descargas automáticas: Los datos esenciales de la aplicación se descargan y guardan directamente en la base de datos. Se inicia cada vez que la aplicación se activa. A medida que completa cada solicitud, se envía una NSNotification para cualquier controlador de vista visible que pueda necesitar conocer sobre los nuevos datos.

Por ejemplo, si guardo los datos del jugador, les enviaré una notificación como "PlayerDataUpdated". Cuando un controlador de vista está visible, escucha las notificaciones. Cuando no está visible, no escucha las notificaciones, ya que cualquier cambio en la base de datos se descubrirá durante viewWillAppear.

descargas

iniciada por el usuario: Para las solicitudes de red iniciadas por el usuario, tales como extracción para actualizar, se debe llamar al método apropiado en NetworkManager desde el controlador de vista que necesita los datos actualizados.