Por ejemplo: supongamos que estoy tomando una lista de nombres y guardándola en una NSMutableArray. ¿Implemento el método de llamar realmente al servidor para recuperar los datos en el controlador (UIViewController) o el modelo (objeto Friends)?Controlador de vista de modelo: ¿El controlador o el modelo recuperan datos del servidor?
Es una decisión de diseño que depende de lo que está tratando de lograr. Si su modelo solo tiene sentido en el contexto de un solo servicio, o si desea que su modelo brinde acceso a todos los datos en el servidor, luego cree la conexión al servidor en su modelo de datos. Esto podría tener sentido si, por ejemplo, está creando un cliente para un servicio como Twitter o Flickr.
Por otro lado, si solo está tomando un archivo de un servidor y eso es todo, puede tener sentido hacer la comunicación en el controlador. Los controladores tienden a ser menos reutilizables y más personalizados para el comportamiento particular de la aplicación. Mantener los detalles acerca de dónde provienen los datos del modelo hace que el modelo sea más reutilizable. También hace que sea fácil de probar: puede escribir un código de prueba que simplemente lea un archivo local y almacene los datos en el modelo.
Esto es lo que estaba tratando, +1 – Nektarios
Esta no debería ser la única razón para tomar una decisión, pero hacer la comunicación cliente-servidor en el controlador también tiene la ventaja de que puede que no sea necesario implementar una [notificación] (https : //developer.apple.com/library/ios/documentation/general/conceptual/devpedia-cocoacore/MVC.html) mecanismo del modelo al controlador. – Drux
Esa es una buena pregunta. Creo que la mejor manera es a través de un controlador porque desacopla su modelo de requerir que el otro modelo esté presente para que funcione correctamente. Aunque tampoco creo que violes el "mvc correcto" al hacerlo en el modelo.
Creo que quieres ponerlo en el modelo. Lo que hará es interrogar al modelo sobre los datos y luego el modelo manejará cómo rellenarse, ya sea desde un almacén de datos interno o externo (como un servidor).
Un enfoque es utilizar el patrón de repositorio. Para hacer esto, crea objetos Repository en su carpeta Model y coloca todos los métodos relacionados con la base de datos en ellos. Sus controladores llaman a las clases de repositorio para obtener los datos. Esto le permite separar los objetos del modelo real de los métodos de acceso a la base de datos.
uso el patrón de MVCS (Modelo-Vista-Controlador-tienda), que descubrí en el libro de Aaron Hillegass "IOS Programación: La Guía de Big Nerd Ranch" (http://www.bignerdranch.com/book/ios_programming_the_big_nerd_ranch_guide_rd_edition_)
La tienda está diseñada específicamente para traer los datos, si provienen de un servidor, un archivo local, una colección persistente, una base de datos, etc.
Permite construir aplicaciones muy evolutivas. Por ejemplo, puedes construir tu aplicación en base a un servicio web, y el día que quieras conservar tus datos, solo tienes que modificar la tienda, sin tener que modificar una sola línea de código en tu controlador.
Es mucho como el patrón de repositorio (http://msdn.microsoft.com/en-us/library/ff649690.aspx) (cf respuesta de BobTurbo)
yo personalmente haría un DAO, o clase de ayuda de datos. Es muy difícil seguir el estricto MVC en el objetivo C cuando las cosas se vuelven más complicadas. Sin embargo, ponerlo en el modelo o el VC tampoco está mal.
Debe estar en el modelo. – doNotCheckMyBlog