Un tutorial introduttivo sui Core Data

Se stai leggendo questo, allora presumo tu sia nuovo ai Core Data. Potresti aver sentito parlare di Core Data e vorresti scoprire se è adatto a te o al progetto a cui stai lavorando. Se questa descrizione si adatta a te, allora accomodati. Questo tutorial sui Core Data ti insegna tutto quello che devi sapere per capire meglio cos’è e cosa non è Core Data.

Che cos’è Core Data

Gli sviluppatori nuovi al framework molto spesso non si prendono il tempo per imparare cos’è Core Data. Non sapere cos’è Core Data rende molto difficile capirne i pro e i contro. Vorrei spendere qualche minuto per esplorare la natura di Core Data e, cosa più importante, chiarire ciò che Core Data è e non è.

Quali sono le sue origini

Core Data è un framework sviluppato e mantenuto da Apple. È stato in giro per più di un decennio e ha fatto la sua prima apparizione su macOS con il rilascio di macOS Tiger nel 2005. Nel 2009, l’azienda ha reso il framework disponibile su iOS con il rilascio di iOS 3.

Dove si inserisce

Core Data è la M di MVC, il livello del modello della vostra applicazione. Anche se Core Data può persistere i dati su disco, la persistenza dei dati è in realtà una caratteristica opzionale del framework. Core Data è prima di tutto un framework per gestire un grafo di oggetti.

Hai probabilmente sentito e letto di Core Data prima di seguire questo corso. Questo significa che potresti già sapere che Core Data non è un database e che gestisce l’object graph della tua applicazione. Entrambe le affermazioni sono vere. Ma cosa significano veramente?

Gestire un Object Graph

Core Data gestisce prima di tutto un object graph. Un grafo di oggetti non è altro che una collezione di oggetti collegati tra loro. Il framework Core Data eccelle nella gestione di grafi di oggetti complessi.

Si occupa di gestire il ciclo di vita degli oggetti nel grafico di oggetti e può opzionalmente persistere il grafico di oggetti su disco. Offre anche una potente interfaccia per la ricerca nell’object graph che gestisce.

Ma Core Data è molto più di questo. Il framework aggiunge un certo numero di altre caratteristiche interessanti, come la validazione dell’input, il versioning del modello di dati e il monitoraggio dei cambiamenti.

Quando usare Core Data

Il framework è perfetto per una vasta gamma di applicazioni, ma non tutte le applicazioni dovrebbero usare Core Data. Le applicazioni che hanno bisogno di un livello di modello leggero non dovrebbero usare Core Data. Ci sono molte librerie leggere che forniscono questo tipo di funzionalità.

Se stai cercando un wrapper per SQLite, allora Core Data non è quello che ti serve. Per un wrapper SQLite leggero e performante, consiglio vivamente FMDB di Gus Mueller. Questa libreria robusta e matura fornisce un’interfaccia orientata agli oggetti per interagire con SQLite.

Core Data è una scelta eccellente se vuoi una soluzione che gestisca il livello del modello della tua applicazione.

Come si differenzia da SQLite

Gli sviluppatori nuovi a Core Data sono spesso confusi dalle differenze tra SQLite e Core Data. Se ti chiedi se hai bisogno di SQLite o di Core Data, allora stai facendo la domanda sbagliata. Ricorda che Core Data non è un database.

SQLite

SQLite è un database leggero che è molto performante e, quindi, adatto alle applicazioni mobili. Anche se SQLite è pubblicizzato come un database relazionale, è importante capire che tu, lo sviluppatore, sei responsabile del mantenimento delle relazioni tra i record memorizzati nel database.

Core Data

Core Data va molto oltre. Fornisce un’astrazione che permette di interagire con il livello del modello in modo orientato agli oggetti. Ogni record con cui si interagisce è un oggetto. Core Data è responsabile dell’integrità del grafico degli oggetti. Assicura che l’object graph sia tenuto aggiornato.

Limitazioni di Core Data

Anche se Core Data è un framework fantastico, ci sono diversi svantaggi. Questi svantaggi sono direttamente legati alla natura del framework e a come funziona.

Core Data può fare la sua magia solo perché mantiene il grafico degli oggetti che gestisce in memoria. Questo significa che può operare sui record solo quando sono in memoria. Questo è molto diverso dall’eseguire una query SQL su un database. Se vuoi cancellare migliaia di record, Core Data deve prima caricare ogni record in memoria. Va da sé che questo comporta problemi di memoria e di prestazioni se fatto in modo non corretto.

Un’altra importante limitazione è il modello di threading di Core Data. Il framework si aspetta di essere eseguito su un singolo thread. Fortunatamente, Core Data si è evoluto drasticamente nel corso degli anni e il framework ha messo in atto varie soluzioni per rendere il lavoro con Core Data in un ambiente multithread più sicuro e più facile.

Per le applicazioni che hanno bisogno di gestire un complesso grafo di oggetti, Core Data è un ottimo strumento. Se hai solo bisogno di memorizzare una manciata di oggetti non correlati, allora potresti trovarti meglio con una soluzione leggera o con il sistema di default dell’utente.

Esplorare lo stack di Core Data

Ora che sai cos’è Core Data e cosa non è, è il momento di ingrandire gli elementi costitutivi del framework. E’ essenziale che tu capisca come le varie classi che fanno funzionare il framework giocano insieme.

Le stelle del framework sono:

• il modello degli oggetti gestiti
• il contesto degli oggetti gestiti
• e il coordinatore del negozio persistente

Questo diagramma mostra come queste classi si relazionano tra loro. Cominciamo con il managed object model.

Managed Object Model

Il managed object model è un’istanza della classe NSManagedObjectModel. Mentre una tipica applicazione Core Data ha un’istanza della classe NSManagedObjectModel, è possibile averne diverse. L’istanza del managed object model rappresenta il modello di dati dell’applicazione Core Data.

Il diagramma sopra mostra che il managed object model è collegato al modello di dati. Il modello di dati è rappresentato da un file nel bundle dell’applicazione che contiene lo schema dei dati dell’applicazione. Lo schema dei dati non è altro che una collezione di entità.

Un’entità può avere attributi e relazioni, che costituiscono il modello dei dati dell’applicazione. Ricordate per ora che il modello di oggetto gestito un’istanza è della classe NSManagedObjectModel e che rappresenta il modello di dati dell’applicazione Core Data.

Managed Object Context

Un contesto di oggetto gestito è rappresentato da un’istanza della classe NSManagedObjectContext. Un’applicazione Core Data ha uno o più contesti di oggetti gestiti, ognuno dei quali gestisce una collezione di oggetti modello, istanze della classe NSManagedObject.

Il diagramma che abbiamo esplorato prima illustra che il contesto di oggetti gestiti riceve gli oggetti modello attraverso un coordinatore di negozio persistente. Mantiene un riferimento al coordinatore del negozio persistente dell’applicazione.

Il contesto dell’oggetto gestito è l’oggetto con cui si interagisce di più. Crea, legge, aggiorna e cancella gli oggetti del modello. Dal punto di vista di uno sviluppatore, la classe NSManagedObjectContext è il cavallo di battaglia del framework Core Data.

Coordinatore del negozio persistente

Il coordinatore del negozio persistente è rappresentato da un’istanza della classe NSPersistentStoreCoordinator e gioca un ruolo chiave in ogni applicazione Core Data. Mentre è possibile avere più coordinatori di archivi persistenti, la maggior parte delle applicazioni ne ha solo uno. Molto, molto raramente c’è bisogno di avere più coordinatori di negozi persistenti in un’applicazione.

Il coordinatore di negozi persistenti mantiene un riferimento al modello di oggetto gestito e ogni contesto di oggetto gestito genitore mantiene un riferimento al coordinatore di negozi persistenti. Non preoccupatevi dei contesti di oggetti gestiti genitori e figli per ora.

Il diagramma precedente ci mostra che un coordinatore di negozio persistente è collegato a uno o più negozi persistenti. Questo ci porta al negozio persistente.

Persistent Store

Ricordo che Core Data gestisce un grafo di oggetti. Il framework è utile solo se il coordinatore dello store persistente è collegato a uno o più store persistenti. Fuori dalla scatola, Core Data supporta tre tipi di negozi persistenti:

• un database SQLite
• un negozio binario

– un negozio in-memoria

Ogni tipo di negozio persistente ha i suoi pro e contro. La maggior parte delle applicazioni usa un database SQLite come negozio persistente. Come ho detto prima, SQLite è leggero e molto veloce. È ottimo per applicazioni mobili e desktop.

Come funziona il Core Data Stack

Ora che sai in cosa consiste il Core Data stack, è il momento di esplorare come funziona in un’applicazione. Il cuore di un’applicazione Core Data è il coordinatore del negozio persistente. Il persistent store coordinator viene istanziato per primo quando lo stack Core Data viene creato.

Ma per creare il persistent store coordinator, abbiamo bisogno di un managed object model. Perché? Il coordinatore del negozio persistente ha bisogno di sapere com’è lo schema dei dati dell’applicazione.

Dopo aver impostato il coordinatore del negozio persistente e il modello di oggetto gestito, viene inizializzato il cavallo di battaglia del Core Data stack, il managed object context. Ricorda che un contesto oggetto gestito mantiene un riferimento al coordinatore dello store persistente.

Con lo stack Core Data impostato, l’applicazione è pronta a usare Core Data per interagire con lo store persistente dell’applicazione. Nella maggior parte dei casi, la tua applicazione interagisce con il coordinatore dello store persistente attraverso il contesto degli oggetti gestiti.

Raramente, se mai, interagisci direttamente con il coordinatore dello store persistente o con il modello degli oggetti gestiti. Come ho detto prima, la classe NSManagedObjectContext è la classe con cui interagisci più frequentemente.

Il contesto degli oggetti gestiti è usato per creare, leggere, aggiornare e cancellare i record. Quando le modifiche fatte nel contesto dell’oggetto gestito vengono salvate, il contesto dell’oggetto gestito le spinge al coordinatore del negozio persistente, che invia le modifiche al negozio persistente corrispondente.

Se la tua applicazione ha più negozi persistenti, il coordinatore del negozio persistente capisce quale negozio persistente deve memorizzare le modifiche del contesto dell’oggetto gestito.

In breve

Ora conosci i fondamenti del framework Core Data. Sei già in vantaggio perché la maggior parte degli sviluppatori salta questo passo. Il prossimo passo che devi fare è iniziare ad usare il framework. Se hai bisogno di una mano, ti consiglio di controllare Mastering Core Data With Swift.