2011-01-27 4 views
5

la documentazione dello stato:qual è il modo 'corretto' di utilizzare objectWithID di NSManagedObjectContext:

... Questo metodo restituisce sempre un oggetto. I dati nella memoria permanente rappresentato da objectID si presume che esistere, se non lo fa, il restituita oggetto genera un'eccezione quando si accesso qualsiasi proprietà (cioè, quando viene licenziato per colpa ). Il vantaggio di questo comportamento di consiste nel fatto che consente di creare e utilizzare gli errori , quindi creare le righe sottostanti in un secondo momento o in un contesto separato.

e nel campione di app 'core ricette' di Apple il risultato del metodo viene utilizzato per popolare un NSFetchRequest, e il risultato del richiesta viene poi utilizzato, con i commenti in tal senso:

// 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]; 

ho ho visto molti esempi (codice di altri e 'iClass' di apple) in cui il risultato di objectWithID viene utilizzato direttamente, ovvero le sue proprietà sono accessibili e elaborate allegramente.

Se objectWithIDsempre essere trattato come un oggetto "forse-questo-esiste"?

Sto chiedendo perché mi sono appena imbattuto in questo e non stavo cercando la sua esistenza.

risposta

4

Ciò che la documentazione Apple sta dicendo che non è per assumere che l'oggetto esiste è l'archivio permanente, solo perché viene restituito un oggetto.

Puoi trattarlo come se lo fosse, accedendo alle sue proprietà e così via, perché in background Core Data accederà all'archivio dati per soddisfare la tua richiesta. Tuttavia, se l'oggetto non esiste nello store, riceverai un'eccezione.

Here's Apple's documentation explaining faults (che è ciò che objectWithID: restituisce).

+0

Immagino che quello che non sto capendo è, quindi, se in qualche modo 'migliore' o 'più corretto' fare il fetchRequest, usando l'oggetto restituito per scoprire se esiste, o è esattamente lo stesso di solo provare ad accedere alle sue proprietà e recuperare un'eccezione perché l'oggetto non esiste? è l'ultimo, una sorta di scorciatoia, o è sconsiderato? – lulu

+0

La risposta è "dipende". Se stai codificando per una situazione in cui sai che l'oggetto esisterà, ad esempio dove l'utente non ha la capacità di eliminare l'oggetto, allora vai avanti. Se potrebbe non esistere, dovrai eseguire la richiesta di recupero o rilevare l'eccezione. Quale è preferibile? Immagino che sia in qualche modo una questione di stile. Probabilmente mi sporgo verso la richiesta di recupero. – paulbailey

+0

grazie, paulbailey. – lulu

1

Ho trovato questo articolo Safely fetching an NSManagedObject by URI per contenere un bel metodo tutto in uno per l'acquisizione di un oggetto utilizzando objectWithID: ma se è risultato essere un errore, andare avanti e recuperarlo. Il metodo dettagliato va un po 'oltre nel trattare gli URI degli oggetti, ma la tecnica di base presentata è un'estensione utile alla discussione in questa domanda.