Un tutoriel d’introduction à Core Data

Si vous lisez ceci, alors je suppose que vous êtes nouveau à Core Data. Il se peut que vous ayez entendu parler de Core Data et que vous souhaitiez savoir s’il est adapté à vous ou au projet sur lequel vous travaillez. Si cette description vous correspond, alors prenez place. Ce tutoriel Core Data vous apprend tout ce que vous devez savoir pour mieux comprendre ce qu’est et n’est pas le Core Data.

Qu’est-ce que le Core Data

Les développeurs qui découvrent le framework ne prennent très souvent pas le temps d’apprendre ce qu’est le Core Data. Ne pas savoir ce qu’est Core Data, rend très difficile la compréhension de ses tenants et aboutissants. J’aimerais passer quelques minutes à explorer la nature de Core Data et, plus important encore, à clarifier ce que Core Data est et n’est pas.

Quelles sont ses origines

Core Data est un framework développé et maintenu par Apple. Il existe depuis plus d’une décennie et il a fait son apparition sur macOS avec la sortie de macOS Tiger en 2005. En 2009, la société a rendu le framework disponible sur iOS avec la sortie d’iOS 3.

Où s’intègre-t-il

Core Data est le M dans MVC, la couche modèle de votre application. Même si Core Data peut persister les données sur le disque, la persistance des données est en fait une fonctionnalité optionnelle du framework. Core Data est avant tout un framework pour gérer un graphe d’objets.

Vous avez probablement entendu et lu des choses sur Core Data avant de suivre ce cours. Cela signifie que vous savez peut-être déjà que Core Data n’est pas une base de données et qu’il gère le graphe d’objets de votre application. Ces deux affirmations sont vraies. Mais que signifient-elles vraiment ?

Gérer un graphe d’objets

Core Data gère avant tout un graphe d’objets. Un graphe d’objets n’est rien d’autre qu’une collection d’objets qui sont connectés les uns aux autres. Le framework Core Data excelle dans la gestion de graphes d’objets complexes.

Il prend en charge la gestion du cycle de vie des objets du graphe d’objets et il peut éventuellement persister le graphe d’objets sur le disque. Il offre également une interface puissante pour rechercher le graphe d’objets qu’il gère.

Mais Core Data est bien plus que cela. Le framework ajoute un certain nombre d’autres fonctionnalités convaincantes, telles que la validation des entrées, le versionnage du modèle de données et le suivi des changements.

Quand utiliser Core Data

Le framework convient parfaitement à un large éventail d’applications, mais toutes les applications ne devraient pas utiliser Core Data. Les applications qui ont besoin d’une couche de modèle légère ne devraient pas utiliser Core Data. Il existe de nombreuses bibliothèques légères qui fournissent ce type de fonctionnalité.

Si vous recherchez un wrapper SQLite, alors Core Data n’est pas non plus ce dont vous avez besoin. Pour un wrapper SQLite léger et performant, je recommande vivement FMDB de Gus Mueller. Cette bibliothèque robuste et mature fournit une interface orientée objet pour interagir avec SQLite.

Core Data est un excellent choix si vous voulez une solution qui gère la couche modèle de votre application.

Comment diffère-t-il de SQLite

Les développeurs qui découvrent Core Data sont souvent confus par les différences entre SQLite et Core Data. Si vous vous demandez si vous avez besoin de SQLite ou de Core Data, alors vous posez la mauvaise question. N’oubliez pas que Core Data n’est pas une base de données.

SQLite

SQLite est une base de données légère très performante et, par conséquent, bien adaptée aux applications mobiles. Même si SQLite est annoncé comme une base de données relationnelle, il est important de réaliser que vous, le développeur, êtes en charge de maintenir les relations entre les enregistrements stockés dans la base de données.

Core Data

Core Data va beaucoup plus loin. Il fournit une abstraction qui vous permet d’interagir avec la couche de modèle d’une manière orientée objet. Chaque enregistrement avec lequel vous interagissez est un objet. Core Data est responsable de l’intégrité du graphe d’objets. Il s’assure que le graphe d’objets est maintenu à jour.

Limites de Core Data

Même si Core Data est un framework fantastique, il y a plusieurs inconvénients. Ces inconvénients sont directement liés à la nature du framework et à son fonctionnement.

Core Data ne peut faire sa magie que parce qu’il garde le graphe d’objets qu’il gère en mémoire. Cela signifie qu’il ne peut opérer sur les enregistrements qu’une fois qu’ils sont en mémoire. C’est très différent de l’exécution d’une requête SQL sur une base de données. Si vous voulez supprimer des milliers d’enregistrements, Core Data doit d’abord charger chaque enregistrement en mémoire. Il va sans dire que cela entraîne des problèmes de mémoire et de performance si cela n’est pas fait correctement.

Une autre limitation importante est le modèle de threading de Core Data. Le framework s’attend à être exécuté sur un seul thread. Heureusement, Core Data a considérablement évolué au fil des ans et le framework a mis en place diverses solutions pour rendre le travail avec Core Data dans un environnement multithread plus sûr et plus facile.

Pour les applications qui doivent gérer un graphe d’objets complexe, Core Data est une excellente solution. Si vous n’avez besoin de stocker qu’une poignée d’objets non liés, alors vous serez peut-être mieux loti avec une solution légère ou le système par défaut de l’utilisateur.

Exploration de la pile Core Data

Maintenant que vous savez ce qu’est Core Data et ce qu’il n’est pas, il est temps de zoomer sur les blocs de construction du framework. Il est essentiel que vous compreniez comment les différentes classes qui font fonctionner le framework jouent ensemble.

Les stars du framework sont :

• le modèle d’objet géré
• le contexte d’objet géré
• et le coordinateur de magasin persistant

Ce diagramme montre comment ces classes sont liées les unes aux autres. Commençons par le modèle d’objet géré.

Modèle d’objet géré

Le modèle d’objet géré est une instance de la classe NSManagedObjectModel. Bien qu’une application Core Data typique possède une instance de la classe NSManagedObjectModel, il est possible d’en avoir plusieurs. L’instance du modèle d’objet géré représente le modèle de données de l’application Core Data.

Le diagramme ci-dessus montre que le modèle d’objet géré est connecté au modèle de données. Le modèle de données est représenté par un fichier dans le bundle de l’application qui contient le schéma de données de l’application. Le schéma de données n’est rien d’autre qu’une collection d’entités.

Une entité peut avoir des attributs et des relations, qui constituent le modèle de données de l’application. Rappelez-vous pour le moment que le modèle d’objet géré une instance est de la classe NSManagedObjectModel et qu’il le modèle de données de l’application Core Data représente.

Contexte d’objet géré

Un contexte d’objet géré est représenté par une instance de la classe NSManagedObjectContext. Une application Core Data possède un ou plusieurs contextes d’objets gérés, chacun gérant une collection d’objets modèles, instances de la classe NSManagedObject.

Le diagramme que nous avons exploré précédemment illustre que le contexte d’objets gérés reçoit des objets modèles par l’intermédiaire d’un coordinateur de magasin persistant. Il conserve une référence au coordinateur de magasin persistant de l’application.

Le contexte d’objet géré est l’objet avec lequel vous interagissez le plus. Il crée, lit, met à jour et supprime les objets de modèle. Du point de vue d’un développeur, la classe NSManagedObjectContext est le cheval de bataille du framework Core Data.

Coordinateur de magasin persistant

Le coordinateur de magasin persistant est représenté par une instance de la classe NSPersistentStoreCoordinator et il joue un rôle clé dans chaque application Core Data. Bien qu’il soit possible d’avoir plusieurs coordinateurs de magasin persistant, la plupart des applications n’en ont qu’un seul. Il est très, très rarement nécessaire d’avoir plusieurs coordinateurs de magasin persistant dans une application.

Le coordinateur de magasin persistant conserve une référence au modèle d’objet géré et chaque contexte d’objet géré parent conserve une référence au coordinateur de magasin persistant. Ne vous préoccupez pas des contextes d’objets gérés parents et enfants pour le moment.

Le diagramme ci-dessus nous montre qu’un coordinateur de magasin persistant est connecté à un ou plusieurs magasins persistants. Cela nous amène au magasin persistant.

Magasin persistant

Rappelez-vous que Core Data gère un graphe d’objets. Le framework n’est utile que si le coordinateur du magasin persistant est connecté à un ou plusieurs magasins persistants. D’emblée, Core Data prend en charge trois types de magasins persistants :

• une base de données SQLite
• un magasin binaire

– un magasin en mémoire

Chaque type de magasin persistant a ses avantages et ses inconvénients. La plupart des applications utilisent une base de données SQLite comme magasin persistant. Comme je l’ai mentionné précédemment, SQLite est léger et très rapide. Il est idéal pour les applications mobiles et de bureau.

Comment fonctionne la pile Core Data

Maintenant que vous savez de quoi se compose la pile Core Data, il est temps d’explorer comment elle fonctionne dans une application. Le cœur d’une application Core Data est le coordinateur de magasin persistant. Le coordinateur de magasin persistant est instancié en premier lorsque la pile Core Data est créée.

Mais pour créer le coordinateur de magasin persistant, nous avons besoin d’un modèle d’objet géré. Pourquoi ? Le coordinateur de magasin persistant doit savoir à quoi ressemble le schéma de données de l’application.

Après avoir configuré le coordinateur de magasin persistant et le modèle d’objet géré, le cheval de bataille de la pile Core Data est initialisé, le contexte d’objet géré. Rappelez-vous qu’un contexte d’objet géré conserve une référence au coordinateur de magasin persistant.

Avec la pile Core Data configurée, l’application est prête à utiliser Core Data pour interagir avec le magasin persistant de l’application. Dans la plupart des cas, votre application interagit avec le coordinateur du magasin persistant par le biais du contexte d’objet géré.

Vous interagirez rarement, voire jamais, directement avec le coordinateur du magasin persistant ou le modèle d’objet géré. Comme je l’ai mentionné précédemment, la classe NSManagedObjectContext est la classe avec laquelle vous interagissez le plus fréquemment.

Le contexte d’objet géré est utilisé pour créer, lire, mettre à jour et supprimer des enregistrements. Lorsque les modifications apportées dans le contexte d’objet géré sont enregistrées, le contexte d’objet géré les pousse vers le coordinateur de magasin persistant, qui envoie les modifications au magasin persistant correspondant.

Si votre application possède plusieurs magasins persistants, le coordinateur de magasin persistant détermine quel magasin persistant doit stocker les changements du contexte d’objet géré.

En un mot

Vous connaissez maintenant les principes fondamentaux du framework Core Data. Vous avez déjà une longueur d’avance car la plupart des développeurs sautent cette étape. La prochaine étape que vous devez franchir est de commencer à utiliser le framework. Si vous avez besoin d’un coup de main, je vous recommande de consulter Mastering Core Data With Swift.

.