Il n'y a pas de tableau ou de type de dictionnaire "natif" dans Core Data. Vous pouvez stocker un NSArray
ou un NSDictionary
comme attribut transformable. Cela utilisera le NSCoding
pour sérialiser le tableau ou le dictionnaire en un NSData
attribut (et le désérialiser de manière appropriée lors de l'accès). L'avantage de cette approche est qu'elle est facile. L'inconvénient est que vous ne pouvez pas interroger le tableau ou le dictionnaire (il est stocké en tant que BLOB dans le magasin de données) et si les collections sont volumineuses, vous devrez peut-être déplacer beaucoup de données vers / depuis le magasin de données (si c'est un magasin de données SQLite) juste pour lire ou modifier une petite partie de la collection.
L'alternative consiste à utiliser des relations Core Data to-many pour modéliser la sémantique du tableau ou de la collection de dictionnaires. Les tableaux sont plus faciles, commençons par là. Les relations Core Data to-many modélisent vraiment un ensemble, donc si vous avez besoin d'une fonctionnalité de type tableau, vous devez soit trier l'ensemble (l'utilisation d'une propriété extraite est un moyen pratique de le faire), soit ajouter un attribut d'index supplémentaire à l'entité qui stocke les éléments du tableau et gère les index vous-même. Si vous stockez un tableau homogène (toutes les entrées sont du même type), il est facile de modéliser la description d'entité pour les entités du tableau. Sinon, vous devrez décider d'utiliser un attribut transformable pour stocker les données d'élément ou créer une famille d'entités d'élément.
La modélisation d'un dictionnaire nécessitera probablement une relation à plusieurs avec un ensemble d'entités qui stocke une clé et une valeur. La clé et la valeur sont toutes deux analogues à l'entité d'élément du tableau, décrite ci-dessus. Il peut donc s'agir de types natifs (si vous les connaissez à l'avance), d'un attribut transformable ou d'une relation avec une instance d'une famille d'entités spécifiques au type.
Si tout cela semble un peu intimidant, c'est le cas. Il est difficile de regrouper des données arbitraires dans un cadre dépendant du schéma comme Core Data.
Pour les données structurées, comme les adresses, il est presque toujours plus facile de passer du temps à modéliser explicitement les entités (par exemple un attribut pour chaque partie de l'adresse). En plus d'éviter tout le code supplémentaire pour modéliser un dictionnaire, cela rend votre interface utilisateur plus facile (les liaisons "fonctionneront") et votre logique de validation, etc. beaucoup plus claire puisqu'une grande partie peut être gérée par Core Data.
Mettre à jour
Depuis OS X 10.7, Core Data inclut un type d'ensemble ordonné qui peut être utilisé à la place d'un tableau. Si vous pouvez cibler 10.7 ou une version ultérieure, c'est la meilleure solution pour les collections ordonnées (de type tableau).