Core Data sembra aggiungere un livello inutile di complessità. Se si desidera salvare i dati creati nativamente dall'utente in un'app, perché non utilizzare solo un oggetto e quindi scrivere tutti i dati su SQLite o su un server utilizzando uno script RESTful, se necessario.
Android non ha Core Data (anche se ha qualcosa di simile, non l'ho visto.). Che diamine è il punto del buggy CD eccetto inutile inutile sovraccarico per le persone che non possono scrivere script SQL o CGI?
È assolutamente possibile scrivere query SQL e archiviare tutti i dati necessari in un database SQLite o semplicemente scrivere dati grezzi in un file. In effetti sei libero di farlo ora in un'app iOS. Perché allora potremmo volere un'astrazione diversa?
Immediatamente noterai che la tua applicazione funziona con gli oggetti e devi tradurli in qualche forma che puoi scrivere nel tuo data store. Potresti semplicemente scrivere un mucchio di byte grezzi dalla memoria al disco, ma sarà molto difficile ricostruirli in un oggetto del tipo appropriato e non appena cambierai la struttura di un oggetto i dati saranno ancora più difficili da recuperare. Invece probabilmente deciderete di serializzare l'oggetto in una forma più ragionevole. Funziona bene se vuoi solo scrivere su un file, ma è difficile ricostruire selettivamente gli oggetti. Nessun problema, puoi archiviare i dati in sqlite in un modulo su cui puoi eseguire una query e ora puoi cercare e caricare rapidamente oggetti specifici. Ovviamente è sconveniente che ogni classe della tua app gestisca un sacco di letture e scritture di database, probabilmente vorrai un servizio che possa automatizzare le classi di mapping a tabelle e oggetti alle righe di quelle tabelle. Ora hai creato la tua libreria di mapping relazionale agli oggetti.
La mappatura degli oggetti alle righe nelle tabelle è un buon inizio, ma alcuni dei tuoi oggetti contengono altri oggetti figlio, quindi devi salvare e caricare interi grafici di oggetti alla volta. Va bene con un po 'di lavoro che puoi gestire anche tu.
Oh e sarebbe bello se potessi ricontrollare che i tuoi dati siano validi prima di salvarli effettivamente, quindi potresti aggiungere alcune regole per impedire il salvataggio di oggetti non validi nel database.
La tua libreria ORM funziona alla grande ma, mentre continui a lavorare sull'app, scopri che è necessario modificare alcuni dei tuoi oggetti. Ciò significa che devi anche cambiare il modo in cui sono rappresentati nel database. Ora è necessario definire un processo per la migrazione di uno schema di database vecchio a uno nuovo.
Man mano che la tua app cresce diventa impossibile memorizzare tutti i risultati di alcune delle tue query in memoria. Lo risolvi con uno schema intelligente per caricare solo pochi oggetti alla volta, quando sono necessari.
Poi scopri che gli utenti a volte vogliono annullare le loro modifiche. Puoi memorizzare ogni modifica come una riga in una tabella, ma dopo averlo fatto un paio di volte ti rendi conto che il tuo servizio di archiviazione dati potrebbe automaticamente tenere traccia delle modifiche per te.
Ora hai uno strumento piuttosto potente per la gestione degli oggetti persistenti nella tua applicazione. È così utile che sarebbe bello se si potesse usarlo anche in altre situazioni, come per gli oggetti che si desidera conservare in memoria e non scrivere in un database. Ovviamente, sarebbe ancora meglio se potessi scegliere di spostare alcuni di questi oggetti nel database più tardi.
Ora hai reinventato la maggior parte dei CoreData. Un tentativo di creare uno strumento abbastanza generico per oggetti persistenti e la gestione di operazioni comuni sulla loro persistenza. Non lo usi per tutto, ma è terribilmente utile per accedere alle tue app non appena hanno alcuni requisiti non banali su come gestiscono i dati.
Leggi altre domande sui tag data-structures sqlite objective-c