2011-01-27 11 views
5

la documentación estado:cuál es la forma 'adecuada' para usar objectWithID de NSManagedObjectContext:

... Este método siempre devuelve un objeto. Los datos en el almacén persistente representado por IDobjeto se supone que existen -si no lo hace, el objeto devuelto lanza una excepción cuando el acceso cualquier propiedad (es decir, cuando se dispara el fallo ). El beneficio de este comportamiento es que le permite crear y usar fallas, luego crear las filas subyacentes más tarde o en un contexto separado .

y en aplicación de ejemplo 'núcleo Recetas' de Apple el resultado del método que se utilice para rellenar una NSFetchRequest, y luego se utiliza el resultado de la solicitud, con comentarios a tal efecto:

// first get the object into the context 
Recipe *recipeFault = (Recipe *)[context objectWithID:objectID]; 

// this only creates a fault, which may NOT resolve to an object (for example, if the ID is for 
// an objec that has been deleted already): create a fetch request to get the object for real 
NSFetchRequest *request = [[[NSFetchRequest alloc] init] autorelease]; 
[request setEntity: [NSEntityDescription entityForName:@"Recipe" inManagedObjectContext:context]]; 
NSPredicate *predicate = [NSPredicate predicateWithFormat: @"(self == %@)", recipeFault]; 
        [request setPredicate: predicate]; 

tengo visto muchos ejemplos (código de otro, y 'iClass' de apple) donde el resultado de objectWithID se usa directamente, lo que significa que sus propiedades son accedidas y procesadas alegremente.

¿Debería objectWithIDsiempre ser tratado como un objeto 'quizás-esto-existe'?

Lo estoy preguntando porque me acabo de topar con esto y no había ido en busca de su existencia.

Respuesta

4

Lo que la documentación de Apple le dice no es suponer que el objeto existe es la tienda persistente, simplemente porque se devuelve un objeto.

Puede tratarlo como si lo hiciera, accediendo a sus propiedades y demás, porque en el fondo Core Data accederá al almacén de datos para atender su solicitud. Sin embargo, si el objeto no existe en la tienda, obtendrá una excepción.

Here's Apple's documentation explaining faults (que es lo que objectWithID: le devuelve).

+0

supongo que lo que no entiendo es, entonces, si de alguna manera es "mejor" o "más apropiado" hacer fetchRequest, utilizando el objeto devuelto para averiguar si existe, o es exactamente lo mismo que solo tratando de acceder a sus propiedades, y obteniendo una excepción porque el objeto no existe? ¿es el último, una especie de atajo, o es desacertado? – lulu

+0

La respuesta es "depende". Si está codificando una situación en la que sabe que el objeto existirá, por ejemplo, donde el usuario no tiene capacidad para eliminar el objeto, continúe. Si no existe, entonces tendrá que hacer la solicitud de búsqueda o atrapar la excepción. ¿Cuál es preferible? Supongo que es una cuestión de estilo. Probablemente me inclinaría hacia la solicitud de búsqueda. – paulbailey

+0

gracias, paulbailey. – lulu

1

Encontré este artículo Safely fetching an NSManagedObject by URI que contiene un buen método todo en uno para agarrar un objeto usando objectWithID: pero si se encuentra que es un error, seguir adelante y buscarlo. El método detallado va un poco más allá al tratar con URI de objetos, pero la técnica central presentada es una extensión útil para la discusión en esta pregunta.

Cuestiones relacionadas