Mejores prácticas de CoreData

Question

Estoy usando CoreData en mi última aplicación de iPhone. Me resulta complejo al principio, pero supongo que esta es la mejor opción cuando necesita almacenar objetos en una aplicación de iPhone (http://inessential.com/2010/02/26/on_switching_away_from_core_data).

¿Existe alguna práctica recomendada al utilizar CoreData en una aplicación de iPhone? Por ejemplo, no quiero que todos mis controladores se ocupen de este NSManagedObjectContext que necesita cuando desea realizar solicitudes. ¿Define una clase solo para solicitudes de CoreData?

Answer 1

Por lo general crear un objeto dedicado a manejar mi pila de datos básicos y los objetos y comportamientos relacionados. Esto es útil porque hay una gran cantidad de placa de caldera con Core Data, así que puedo crear una clase genérica de administrador de base y luego usar una subclase para cada aplicación. Normalmente lo llamo AppNameDataModel.

Prefiero ocultar el contexto del objeto gestionado dentro del objeto DataModel. Esto fuerza a los otros objetos de la aplicación a solicitar al objeto DataModel el acceso a la pila de datos básicos, lo que proporciona una buena encapsulación y seguridad.

Normalmente, creo métodos en la clase DataModel para devolver capturas para entidades, p.

-(NSFetchRequest *) entityNameFetch; 

... y luego tienen un método performFetch en el DataModel. En uso, un controlador solicita una recuperación para una entidad, configura la recuperación y luego le pide al DataModel que realice la recuperación y devuelva los resultados. Puede guiar la generación de los métodos que devuelven la búsqueda y la recuperación de la ejecución también es la placa de la caldera. Todo esto ahorra mucho tiempo, especialmente al crear prototipos.

Se puede pasar una referencia a la instancia de DataModel del controlador al controlador, pero creo que es un uso válido del patrón singleton, por lo que a menudo el DataModel es un singleton y proporciona una categoría en UIViewController para que una propiedad acceda a él .Eso significa que cualquier controlador de vista que agregue al proyecto automáticamente tiene acceso al modelo de datos.

Este patrón mantiene todo muy bien encapsulado y modular. Hace que sea fácil agregar nuevas vistas o compartir el modelo de datos entre proyectos. Se necesita un poco de trabajo para configurar inicialmente, pero una vez que tienes la clase base, el uso futuro se acelera masivamente.

Answer 2

Gracias Brad por señalar a esta pregunta.

Como se menciona en la documentación de Apple [1], el contexto se debe pasar a cada controlador de vista nuevo que necesite CoreData.

En el iPhone:

Por convención, a menudo se puede obtener un contexto de un controlador de vista. Depende de usted, sin embargo, seguir este patrón. Cuando implementa un controlador de vista que se integra con Core Data, puede agregar una propiedad NSManagedObjectContext.

Un controlador de vista normalmente no debe recuperar el contexto de un objeto global como el delegado de la aplicación. Esto tiende a hacer que la arquitectura de la aplicación sea rígida. Tampoco debe un controlador de vista crear un contexto para su propio uso. Esto puede significar que las operaciones realizadas utilizando el contexto del controlador no se registran en otros contextos, por lo que diferentes controladores de vista tendrán diferentes perspectivas sobre los datos.

Cuando crea un controlador de vista, le pasa un contexto. Pasa un contexto existente o (en una situación en la que desea que el nuevo controlador administre un conjunto discreto de ediciones) un nuevo contexto que cree para él. Por lo general, es responsabilidad del delegado de la aplicación crear un contexto para pasar al primer controlador de vista que se muestra.

[1] - http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/CoreDataSnippets/Articles/stack.html#//apple_ref/doc/uid/TP40008283