Patrón de diseño para Core Data iPhone App

Question

Im construyendo una aplicación que utilizará un modelo Core Data. Soy bastante nuevo en Objective C y mis patrones de diseño habituales no se aplican realmente en Core Data y Objective C, al menos no puedo encontrar ejemplos que confirmen que lo harán.

He pasado por los ejemplos de desarrollador de Apple y diferentes fuentes en los intertubos.

Parece que para aprovechar la base de datos que necesita para pasar el managedObjectContext a cada uno de mis viewControllers, tener la viewController implementar el NSFetchedResultsControllerDelegate y luego poner en práctica cada uno de los métodos para hacer una zona de alcance, y posteriormente aplicar

NSFetchedResultsChangeInsert 

NSFetchedResultsChangeDelete NSFetchedResultsChangeMove NSFetchedResultsChangeUpdate

Esto añade aproximadamente más de 100 líneas de código en cada viewController y es el 90% del mismo código que escribo una y otra vez. Además, tengo que pasar todo por alto y hacer un seguimiento de su huella de memoria.

En otros idiomas construiría un modelo singleton de unas pocas clases que contenían métodos para mantener y entregar datos a pedido, disponibles desde cualquier lugar. Parece que no puedo tomar ese enfoque en Objective C. Si fuera a construir una clase estática que tomara un managedObjectContext y me devolviera lo que necesitaba, igual tendría que pasar el managedObjectContext a cada vista y no sería asincrónicamente me gusta cuando implemento métodos de delegado que recién se llaman cuando un resultado está listo.

Espero que esto tenga sentido y que alguien pueda confirmar que no hay otra manera razonable de hacerlo o ayudarme a orientarme en una dirección para completar esto de una buena manera.

Gracias :)

Answer 1

de Datos Básicos no es tan complicado como usted describe.

Generalmente, una aplicación de iPhone tiene un contexto de objeto administrado "principal", que generalmente es propiedad del delegado de la aplicación. Siempre que pueda obtener el delegado de la aplicación (sugerencia: [[UIApplication sharedApplication] delegate]) tiene acceso al contexto del objeto gestionado. Me gusta definir una variable global estática para mantener una referencia al delegado de mi aplicación para facilitar la vida.

Generalmente hay una correspondencia uno a uno entre instancias NSFetchedResultsController y UITableView instancias. Además de poblar vistas de tabla, es extremadamente raro que necesite un NSFetchedResultsController. Si tiene una cantidad de vistas similares (por ejemplo, una barra de pestañas que le permite ver los mismos datos de diferentes maneras al igual que la aplicación iPod), le convendría crear una única clase base que configure el NSFetchedResultsController y derivar sus controles de vista específicos. a partir de ese.

Ahora, cuando crea controles de vista para editar un objeto, generalmente es una buena idea hacerlo en un contexto de objeto gestionado separado. Si el usuario cancela, simplemente descarta el contexto y los cambios desaparecen. Nuevamente, realmente no necesita un NSFetchedResultsController para esto porque estas vistas solo se refieren a un solo objeto.

Cuando termine de editar, save: el contexto del objeto administrado. Los objetos que gestionan sus otros contextos de objetos gestionados deben implementar los métodos NSFetchedResultsControllerDelegate para mantener sincronizada la vista de tabla. De nuevo, esto se puede implementar en una clase base para que pueda generalizar esta funcionalidad para los controladores de vista relacionados.

Answer 2

No es absolutamente necesario utilizar un modelo CoreData, o sería algo utilizando un NSCoder (NSArchiver, NSKeyedArchiver, etc.) trabajar? Descubrí que CoreData es excesivo para la mayoría de las aplicaciones.

Además, ¿podría aclarar por qué no puede adoptar un enfoque utilizando singletons? He utilizado fábricas de singleton en una serie de aplicaciones sin problemas. Es bastante fácil definir métodos a nivel de clase que operan en una instancia compartida (singleton).