Core Data vs. SQLite pour la persistance hors ligne d'une base de données existante exposée via OData

Question

Je suis en train de créer une application qui nécessite une persistance "hors ligne" de ses données qui sont exposées via un service web OData. Le service OData me donne accès à toutes les tables de la base de données sous-jacente, ainsi qu'à tous les champs de base de données pertinents tels que les ID.

De plus, j'ai déjà un schéma de base de données SQLite que je peux utiliser.

Ma question, sur laquelle j'ai déjà fait volte-face deux fois, est de savoir s'il est préférable de stocker les données du service web sur le dispositif via SQLite directement (en utilisant FMDB), ou de tirer parti de Core Data ?

Si j'utilise Core Data, je perds les avantages relationnels des clés primaires et étrangères, mais je gagne l'avantage des NSManagedObjects automatiquement imbriqués/peuplés. Je ne suis pas totalement sûr de la meilleure façon de recréer la nature relationnelle de mes objets de données.

Si j'utilise SQLite, je peux simplement insérer/mettre à jour les résultats des appels au service web, et obtenir automatiquement les relations à partir des colonnes de clés étrangères existantes. L'inconvénient est que je dois probablement encapsuler manuellement mes résultats dans des objets POCO.

Pour l'instant, mon instinct me dit SQLite, mais il semble que la communauté s'oriente massivement vers Core Data dans tous les cas. Si j'opte pour Core Data, quelle est la meilleure façon de créer et de maintenir les relations entre objets (surtout lorsqu'elles sont de type 1->many) ?

Cette application n'entrera pas dans l'App Store, si des aspects de l'Apple-happy sont en cause.

Answer 1

Core Data modélise directement les relations. Ainsi, dans votre schéma, vous pouvez dire, par exemple, que l'objet A a une relation avec l'objet B et que cette relation est "vers plusieurs". Cependant, les relations fonctionnent comme des références d'objets normales - vous devez lier chaque instance de A à toutes les instances pertinentes de B, vous ne pouvez pas [facilement, ou habituellement] dire simplement "A est lié à B par la clé étrangère bID" et ensuite laisser la relation se gérer d'elle-même.

Si vous avez un magasin persistant SQL, la façon dont cela est mis en œuvre est que chaque objet obtient une clé unique implicite pour sa table. Les relations sont modélisées comme une colonne supplémentaire qui contient la ou les clés de chaque objet lié dans la table étrangère.

D'autres choses que les gens ont tendance à ne pas aimer à propos de Core Data :

• si vous vous fiez systématiquement aux récupérations de données implicites, vous obtiendrez souvent des performances médiocres, de sorte que vous finissez souvent par utiliser des requêtes explicites afin d'alimenter les résultats que vous êtes probablement sur le point de consulter en un seul voyage dans la base de données ;
• étant donné que SQLite n'est pas thread safe et que les objets Core Data maintiennent une connexion en direct avec leurs magasins, les objets Core Data ne sont pas thread safe (bien que objectID et vous pouvez récupérer des dictionnaires de sécurité similaire au lieu d'objets vivants si vous préférez) ;
• même si vous avez résolu le problème du threading, les sauvegardes en arrière-plan bloquent toujours les accès en avant-plan, conformément au commentaire sur la sécurité des threads de SQLite.

Inversement :

• Depuis iOS 5, vous pouvez utiliser NSIncrementalStore de sorte qu'il vous suffit d'exécuter des requêtes Core Data et que votre magasin Core Data est suffisamment intelligent pour se rendre sur le serveur si nécessaire. Le corps principal de votre code ne sait pas si les données sont locales ou distantes et n'a pas besoin de se répéter lorsqu'il déclare ce qu'il va rechercher ;
• vous bénéficiez gratuitement de la connexion à la base de données en direct, de sorte que vos objets se mettent automatiquement à jour si le magasin persistant change ;
• si vous cherchez principalement à faire des vues de table de type iPhone, le travail est déjà presque entièrement fait pour vous, il suffit de fournir la requête ;
• Core Data dispose d'un système sophistiqué de défaillance qui résout en grande partie les problèmes d'encombrement de la mémoire lors du traitement de grands ensembles de données.