2011-12-17 14 views
7

FMDB Wrapper VS Core Data: che è più facile da usare & mantenere?FMDB Wrapper VS Core Data: che è più facile da usare e mantenere?

Sono confuso perché FMDB è molto vecchio, ma molti sviluppatori lo stanno usando, mentre Core Data è nuovo ed è supportato solo da sdk 3.0 e successivi.

Alcuni hanno detto che FMDB è facile da usare e alcuni hanno detto Core Data. Per favore aiutami così posso andare nella giusta direzione.

Grazie in anticipo

+1

Per quanto riguarda il commento "supportato solo da 3.0 e versioni successive sdk", Apple non accetta più applicazioni per l'App Store che hanno come target una versione del sistema operativo precedente alla 3.0, quindi questo è un non problema. –

risposta

19

Ho usato entrambi pesantemente su molti progetti ora.

FMDB è molto semplice, se si conosce SQL può anche essere piuttosto facile da usare. Ma che cosa si deve fare attraverso il ciclo di vita di un app, come il modello di dati cambia è:

  1. Modificare il modello di dati, in genere con qualcosa come Base
  2. codice
  3. Change SQL per riflettere modello cambia
  4. Modifica dati oggetti per riflettere le modifiche del modello
  5. Aggiungere il codice nell'app per gestire il caso in cui si incontra il precedente database .

Cosa Core Data porta al ciclo di vita è questo:

  1. modello di dati e gli oggetti vengono modificati con la stessa azione (sono assumendo si genera gli oggetti di dati con qualcosa di simile mogenerator).
  2. Visualizzazione più semplice del modello di dati.
  3. Incoraggia più facilmente a superare i modelli di dati facendoti pensare alle relazioni inverse .
  4. Spesso la migrazione automatica è sufficiente per la transizione attraverso le semplici modifiche del modello senza dover ricostruire il DB da zero.
  5. I dati principali offrono integrazione con iCloud tramite NSManagedDocument.

L'inferno che Core Data si mette attraverso è:

  1. Soppressione fa schifo, perché ogni accesso di immobili a un oggetto eliminato lancia un programma di uccidere eccezione.
  2. Sfondo accesso ai dati filo fa schifo, perché Core Data rende complesso per funzionare correttamente con più thread - non si può per esempio utilizzare un oggetto di dati è stato ottenuto da un contesto in un thread in un altro thread diverso. Così tanto per il semplice passaggio degli oggetti ai thread di sfondo per il lavoro con ...
  3. C'è così tanta magia che gira intorno ai tuoi dati che QUANDO le cose vanno sbagliato sarà terribilmente frustrante cercare di capire cosa fare a fare.
  4. I dati di base sembrano terribilmente fragili, cose come gli oggetti eliminati che lanciano eccezioni, usando dal thread sbagliato lanciare eccezioni, convalide lanciare eccezioni, o l'intero modello svanire dopo quello che sembrava un semplice cambiamento sono tutte possibilità.

Quindi cosa consiglierei? Per parafrasare la vecchia citazione sulla democrazia, Core Data è il peggior sistema di persistenza dei dati - tranne che per tutti gli altri. Anche con la nuova definizione di dolore e sofferenza che i Core Data porteranno nella tua vita, è ancora meno il lavoro e più facile da lavorare rispetto a FMDB o altri livelli di persistenza dei dati.

FMDB è più semplice e se si sta accettando di apportare molto più tempo alle modifiche e la definizione del modello di dati potrebbe essere corretta. Ma generalmente raccomanderei alle persone di mordere il proiettile e utilizzare i dati di base a meno che non ci sia una ragione chiara per non farlo.

alcuni suggerimenti rapidi:

  • Non eliminare mai nulla in Core Data, mentre l'interfaccia utente è alto e possibilmente oggetti di accesso.
  • Se possibile considerare il database come disponibile e in grado di ricostruire il contenuto , in modo che se l'automazione non funziona, l'utente può ancora eseguire l'app .
  • Mantieni tutta l'attività di dati di base sul thread principale e inserisci solo lo sfondo come ultima risorsa.
  • Non utilizzare in nessun caso le convalide dei dati principali o deselezionare mai il campo di attivazione "facoltativo" delle proprie entità. Quale preferiresti avere, un brutto valore scivolare nel tuo modello che potrebbe finire per apparire divertente o semplicemente in crash?
  • Utilizzare mogenerator per generare oggetti dati dal modello. Emette oggetti direttamente legati al modello che la rigenerazione può cambiare, e un livello di oggetti di tipo "sopra" che inizia in bianco ma in cui è possibile aggiungere la logica personalizzata attorno agli oggetti dati e non verrà modificato quando gli oggetti inferiori sono rigenerati.
+0

Risposta fantastica! – jrturton

+0

Non dico che il supporto multithread di CoreData faccia schifo. Devi solo seguire le regole scritte, vedere ad es. http://stackoverflow.com/questions/2138252/ – Yuji

+0

Super Risposta, sono il nuovo utente di questo sito e questo è il motivo per cui non sono accettato questo tipo di risposta, semplicemente eslpai ogni cosa in dettaglio molto d'aiuto. Grazie mille – freelancer

0

A meno che non si dispone di alcuni requisiti specifici del progetto, vorrei utilizzare Core Data. Apple la migliora costantemente e l'ha ottimizzata per l'iPhone.

+0

grazie per la risposta, sento anche che è bello usare i dati di base. – freelancer

0

FMDB Wrapper è più facile da configurare (si può semplicemente aggiungere dati nel db sqlite tramite Firefox Plugin SQLitemanager o utilizzare un altro gestore SQLite per inserire il tuo database), più facile per eseguire il debug (si può effettivamente visualizzare in tempo reale cosa sta cambiando nel tuo database), più facile da capire, più facile da imparare, più facile da portare (al web o Android). Core Data è un gigantesco kludge mal progettato, scarsamente implementato, scarsamente documentato e superintuitivo.

+1

Aggiungi un esempio di * come * per configurare FMDB alla tua risposta. Questo sembra più un commento ora. – Adriaan

Problemi correlati