Sono stato alla ricerca di un articolo che spiega NSCoding (NSKeyedArchiver ...) vantaggi e svantaggi sull'uso di CoreData (SQLite ....).NSCoding VS Core dati
C'è un sacco di opzioni, posso implementare il mio lettore/scrittore binario personalizzato, o usare plists/xml/json ... o usare SQLite o NSCoding.
Sono quasi perso. Qualcuno può spiegare qual è la differenza tra le caratteristiche principali?
Dipende dal tipo di dati che si desidera salvare e se lo si utilizzerà solo internamente o si deve scambiare i dati con un servizio esterno.
NSCoding è in genere un serializzatore di dati. Un sacco di oggetti built-in implementa il protocollo NSCoder che consente di salvarli come flusso binario (file, in un BLOB di un sqlite, ecc.) NSKeyedArchiver offre il vantaggio di cercare in tali flussi in base a un'etichetta stringa , un po 'come un dizionario ma puoi usare solo le stringhe come chiavi. Questo approccio è utile se occasionalmente si devono mantenere alcuni oggetti di classi diverse.
Tuttavia, se si dispone di molti oggetti della stessa classe di, sarete meglio andare per un database-approccio, SQLite o CoreData. CoreData è praticamente un wrapper su SQLite che facilita molto la progettazione del tuo modello dati, e fa le query al DB dietro le quinte, senza la necessità di scrivere istruzioni SQL. In CoreData definisci le tue classi e ogni istanza della classe può essere persistente, cioè puoi recuperare i valori dei membri dell'oggetto senza averli sempre nella memoria. Questo è un modo molto conveniente per memorizzare molti dati strutturati. Ad esempio se si scrive un browser Web, è possibile memorizzare i segnalibri dell'utente con il nome, l'URL e forse l'ultima ora visitata.
Per XML e JSON non vi sono particolari vantaggi se si utilizzano i dati solo localmente sul dispositivo. Se è necessario comunicare con un servizio esterno, è possibile prendere in considerazione la possibilità di memorizzare/salvare in cache gli oggetti XML/JSON così come sono per un uso futuro. Un altro approccio sarebbe quello di rigenerare questi dati dalle strutture dati interne (vedi sopra) ogni volta che ne avete bisogno.
Se progettate voi stessi il vostro modello di dati, vedo ancora meno punti per usare i plists, ma forse qualcuno mi correggerà.
MODIFICA: aggiungo qui un breve riferimento di riferimento per esercitazioni su come utilizzare NSCoding, Core Data e come bonus, SQLite.
AGGIORNAMENTO 12.01.2016: Se stai cercando soluzioni di persistenza, ti suggerisco di dare un'occhiata allo Realm.
se i file blob di un sqlite sono serializzati, ciò potrebbe significare che la serializzazione è la migliore per ottenere i pezzi più piccoli di dati binari. È inoltre possibile utilizzare NSCoding per conditionalObjectEncodings, che rimuove la duplicazione delle istanze di oggetti in memoria in memoria. Il motivo per cui sto facendo questa domanda, è perché tutti parlano e suggeriscono Coredata-SQLite, ma non vedo VANTAGGIO A meno che non si stia costruendo contro un'enorme fonte di dati e non si possa mettere tutto ciò in memoria. Ho ragione? – LolaRun
C'è sempre un equilibrio tra memoria e ottimizzazione delle prestazioni. Con NSCoding, o la tua rappresentazione binaria personalizzata hai molto più controllo sui bit scritti nella memoria o memorizzati nella memoria, ma per questo devi pagare il prezzo della codifica più quindi l'efficienza del codice dipenderà dal tuo abilità. Con CoreData/SQLite molte cose utili sono implementate per te in modo efficiente (ricerca, interrogazione, indicizzazione, join, ecc.). Nota: gli oggetti CoreData vengono caricati nella memoria solo quando necessario, altrimenti rimangono nel db. – MrTJ
Eccellente. Quindi, se sto usando il modello di applicazioni "ApplicationDocument", e se ho bisogno di salvare e aprire documenti, non avrei davvero bisogno dei vantaggi di CoreData, dato che ho bisogno di caricare tutto in memoria, e non ho bisogno di interrogare e ... funzionalità del database. La principale differenza è il costo di sviluppo. Che nel mio caso non è una battuta d'arresto. Molte grazie. Aspetterò un po ', per attirare più risposte e più discussioni, prima di accettare una risposta – LolaRun
C'è sempre un'impedenza tra oggetti e strutture relazionali. Preferisco sempre gli oggetti poiché l'accesso ai dati è in genere una frazione della funzionalità della tua app. Con NSCoding, si ottiene semplicità, facilità di debug e controllo con pochissimo codice per scrivere comunque. Hai anche la flessibilità di incorporare NSCoding nelle strutture del tuo database.
NSCoding è un meccanismo di persistenza per il salvataggio di oggetti. Se si aggiungono indici alle strutture relazionali per l'ottimizzazione della ricerca e si mantengono strutture di oggetti, allora penso che si ottenga il meglio di tutti i mondi a costi molto bassi e facilità di manutenzione.
Mattt Thompson fornisce una ripartizione digeribile di varie differenze tra NSCoding, Core Data, e NSKeyedArchiver su NSHipster: http://nshipster.com/nscoding/
grazie, questa è una spiegazione chiara. – LolaRun
da aggiungere al già grandi risposte, NSCoding con NSKeyedArchiver è un ottimo modo per memorizzare i dati che è troppo grande (o incompatibile tipo di dati) per NSUserDefaults ma troppo piccolo e non numeroso per CoreData.
Possibili duplicati: http://stackoverflow.com/questions/4989609 http://stackoverflow.com/questions/840634 –
la cosa è sqlite è considerata all'interno di coredata. E il primo link che hai suggerito, parla specificamente di sqlite3 vs nscoding; con non molte risposte. Sto facendo una domanda più generale. Perché ci sono così tante opzioni per gestire i dati. – LolaRun