Utilizzo di sottoclassi NSManagedObject per il trasporto di dati persistenti e non persistenti

Question

Ho alcune considerazioni su come utilizzare le sottoclassi NSManagedObject di alcuni dati principali per gestire dati persistenti e dati non persistenti.

Supponiamo che tu abbia un'app di ricette che mostra un elenco delle tue ricette da CoreData e in questa stessa app puoi anche cercare le ricette di altri utenti. Queste ricette di altri utenti sono ovviamente da un'API e non vogliamo salvarle nei dati principali. Ma quello che vogliamo invece è il nostro dettaglio della ricetta Visualizza il controller per agire allo stesso modo è data una ricetta persistente o una ricetta non persistente. Naturalmente penso che dovremmo usare lo stesso object wrapper attorno ai nostri dati e lasciare che il nostro View Controller sia cieco sull'origine dei dati.

Il problema è che le sottoclassi NSManagedObject non possono essere inizializzate manualmente e devono essere inserite nel contesto. Non va bene per le ricette degli altri utenti. D'altra parte per le nostre ricette abbiamo bisogno che questi oggetti siano inseriti nel contesto.

Ho in mente un paio di soluzioni, ma mi piacerebbe davvero leggere quello che pensate di questo problema.

Diresti che questo è un problema di implementazione e dovrebbe essere risolto avvolgendo entrambi gli oggetti di dati in un unico oggetto? Per esempio sovrascrivendo tutti i getter e setter per gestire sia gli oggetti coredati che gli oggetti NSDictionary?

Oppure si tratta di un problema di architettura e lo si risolve, ad esempio, annidando NSManagedContext o utilizzando più archivi persistenti (uno in memoria e l'altro Sqlite)?

Answer 1

In realtà è possibile creare istanze NSManagedObject senza inserirle in un contesto. Basta passare nil come argomento del contesto dell'oggetto gestito. Fare qualcosa di simile:

NSEntityDescription *myRecipeEntity = [NSEntityDescription entityForName:@"MyRecipeEntity" inManagedObjectContext:[self managedObjectContext]]; 
MyRecipeClass *recipe = [[MyRecipeClass alloc] initWithEntity:myRecipeEntity insertIntoManagedObjectContext:nil]]; 

Ora si dispone di un'istanza ricetta che non è in alcun contesto.

Se successivamente si desidera aggiungere a un contesto:

[[self managedObjectContext] insertObject:recipe]; 

Se non si desidera inserire, basta buttare via.

Answer 2

Probabilmente userò solo un contesto separato che non si salva mai, che sembra essere il percorso più semplice.

Answer 3

Configurazioni del modello: archivio in memoria e archivio backlite sqlite.

Vorrei prendere seriamente in considerazione l'utilizzo di configurazioni del modello e due tipi di archivio persistenti: in memoria e sqlite.

Ma significa anche che è necessario creare entità separate per dati scaricabili che annullano l'idea che è possibile avere alcune ricette persistenti e alcune temporanee mentre sono entrambe ricette. Inoltre, non è possibile avere relazioni tra entità in diversi archivi persistenti. Rinuncerai al beneficio delle relazioni inverse e dovrai imitare questo con le proprietà recuperate, per esempio.

Tutto sommato, è una scelta praticabile con alcuni svantaggi.

isolato Contesto Managed Object

Il più grande vantaggio di utilizzare contesti oggetto gestito separati è possibile utilizzare la stessa entità ricetta sia per i dati persistenti e temporanei. Dovrai evitare di salvare il contesto temporaneo e dovrai inserire tutte le modifiche dallo store persistente o unire da un altro contesto con i dati salvati.

La sfida con questa alternativa è che è necessario costruire la maggior parte dell'interfaccia utente in cima a questo contesto isolato per la lettura, ma tutte le modifiche permanenti che si rendono necessarie devono essere salvate nel contesto principale e propagate indietro attraverso l'unione nell'isolato contesto. Questo potrebbe introdurre alcune situazioni complicate, ma è fattibile credo.