Práctica recomendada para objetos temporales en RestKit con Core Data

Question

Antecedentes: Tengo un objeto administrado, Car. Tengo una API de búsqueda RESTful sentada en localhost/cars/search. Los resultados devueltos son objetos Car del lado del servidor, pero solo quiero guardar el que el usuario elija. El resto de los autos que quiero descartar cuando vuelven a salir de la búsqueda.

Al principio era todo como:

@interface Car : NSManagedObject //<--- managed object 

    @property (nonatomic, strong) NSNumber* year; 
    @property (nonatomic, strong) NSString* make; 
    @property (nonatomic, strong) NSString* model; 

@end 

@interface TransientCar : NSObject //<--- regular NSObject! 

    @property (nonatomic, strong) NSNumber* year; 
    @property (nonatomic, strong) NSString* make; 
    @property (nonatomic, strong) NSString* model; 

@end 

me mapeo de la búsqueda API REST resultados JSON en objetos TransientCar a efectos de mostrar los resultados de búsqueda, pero no guardarlos en el contexto. De forma predeterminada, si mapea un objeto administrado, RestKit llamará a su objeto fábrica + objeto para crear el objeto e insertarlo en el contexto actual (codificado en el contexto de la tienda de objetos de sharedManager, por cierto!)

Esto parecía insostenible. Así que ahora sólo estoy usando NSMutableDictionary para contener los datos de resultados de búsqueda hasta que el usuario pulsa en una vista en detalle y hace algo vale la pena ahorrar un objeto real administrado por:

RKObjectMapping* tempCarMapping = [RKObjectMapping mappingForClass:[NSMutableDictionary class]]; 
[tempCarMapping mapKeyPathsToAttributes: 
@"year", @"year", 
@"make", @"make", 
@"model", @"model", 
nil]; 

Es esta una buena práctica? ¿Usar NSMutableDictionary como representación temporal hasta que el usuario haga algo que justifique insertar un nuevo objeto en el contexto? Me encantaba usar la subclase original de objetos gestionados para representar los datos, pero de alguna manera podía marcarla como "no mantener" o algo así, pero cada vez que hago eso siento que estoy luchando contra el marco (y condiciones de carrera). También he intentado usar un contexto de cero/desechable mediante la creación de un nuevo RKObjectManager y simplemente despejar toda su contexto más tarde, pero el método + managedObjectContext, bajo la categoría ActiveRecord de RestKit está codificado para volver:

[[[RKObjectManager sharedManager] objectStore] managedObjectContext]; 

Ese tipo de portillos la posibilidad de utilizar siempre un contexto de raspado para datos de temperatura/basura.

Answer 1

En primer lugar, he hecho esto en el pasado utilizando su método de tener dos copias del modelo, una que es para Datos del núcleo y otra que es transitoria (solo un objeto NSO). Eso funcionó sin ningún problema para mí.

En cuanto a sus otros intentos, no creo que la biblioteca fuerce su mano tanto como usted piensa. Mire la API para RKManagedObjectStore y NSManagedObject+ActiveRecord. En particular, RKManagedObjectStore tiene una propiedad managedObjectContext, un método - (NSManagedObjectContext*)newManagedObjectContext y varios métodos para fusionar cambios.

Tiene razón en que [NSManagedObject managedObjectContext] siempre devuelve el contexto del sharedManager, pero tiene sentido, es un método de clase. De lo contrario, ¿cómo sabría la clase qué contexto devolver? Pero es discutible ya que hay muchas otras maneras de crear nuevos contextos y acceder a ellos. O dejando de lado eso por completo, puede mantener una referencia a su contexto temporal y usarlo directamente.

Esto le ofrece algunas opciones: tener varios ObjectManagers, tener un administrador de objetos pero crear un contexto temporal y solo conservar los objetos que desee, crear un objeto transitorio basado en el objeto administrado.

La opción NSMutableDictionary no parece tan flexible como los otros métodos, pero no diría que es una "mala práctica".

Answer 2

También puede ver esta respuesta: Better Approach for Creating Temp Object for Core Data with Restkit

Se evitará el problema objeto transitorio mencionado en la respuesta por Evan Cordell, que es un importante contribuyente a RestKit.

Answer 3

Lamentablemente, todavía no tengo suficiente reputación de StackOverflow para poner esta respuesta donde corresponde (como los comentarios a las otras respuestas), pero quería agregar algunos puntos.

Creo que la respuesta de Evan Cordell es defectuosa. La versión actual de restkit (0.10.x) no le permite crear contextos para que utilice RKManagedObjectLoaders, y los RKObjectManagers pueden tomar una tienda, pero tiene que ser de tipo RKManagedObjectStore, que está explícitamente vinculado a sqllite. La versión dev de restkit (0.20) aparentemente relaja eso, así que puede hacer que guarde los datos en una base de datos en memoria. Intenté sobreescribir los métodos de RKManagedObjectStore para usar un contexto que proporcioné, pero no funcionó ... en cualquier caso, la corrección parece ser no trivial.

El otro enlace dado, Better Approach for Creating Temp Object for Core Data with Restkit, parece tener que ver con publicar un objeto y recibir el mismo objeto en la respuesta. Es un problema diferente de lo que se planteó en esta pregunta.

Hasta que se publique v.0.20.x, lo que esperamos que sea pronto, parece que una jerarquía de clases paralelas es la única opción. ¡Si soy incorrecto, doy la bienvenida a la corrección en este punto!