CoreData et modèles multiples - A votre avis ?

pixman

Bonjour,

Cela fait un petit moment que je me suis fait la main avec core data, et c'est un vrai plaisir à  utiliser. Je trouve qu'on y gagne pas mal de temps !

J'ai une petite question.
j'ai une application qui utilise un modèle pour gérer ses données.
Dans cette appli je veux utiliser une librairie ( que j'ai crée ) afin d'afficher des média.
ma librairie ( chargée d'afficher le médias ) devrait sous peu utiliser son propre modèle coreData pour son organisation interne.
(pour le moment je suis basé sur du XML et une série de classes perso très lourdes, mais facilement remplaçables par un modèle coreData.)

L'idée est de pouvoir franchement séparer le modèle utilisé par la librairie et celui de l'application hôte, et de ne conserver qu'un lien faible entre les deux.

En gros j'imagine stocker le fichier *.sqlite des données utilisées par ma librairie dans le persistent store de l'application, et de passer cette donnée à  ma librairie lorsque je l'exécute afin qu'elle fonctionne en autonomie.


En théorie ça me semble une bonne idée, mais j'aurais souhaité avoir des conseils et retours d'expériences si vous en avez ?

merci

FKDEV

Donc tu auras le même modèle dans la librairie et dans l'application ?

Ok mais il ne risque pas d'avoir des problèmes d'acces concurrents sur le fichier .sqlite ?

Il faut etre sur que les deux auront toujours bien le même modèle.

C'est un peu inhabituel comme interface mais pourquoi pas ?

pixman

Bonjour,

En fait non, je souhaite avoir un modèle pour ma librairie,  qui sera donc utilisée avec son propre persistent store ( son fichier *.sqlite a elle ). Et un modèle spécifique à  l'application hote, pour gérer ses données ( avec son propre persistentStore aussi ).

Le seul moment ou les deux modèles se croisent, c'est lorsque l'application hote "appelle" la librairie, en lui donnant le fichier *.sqlite qui va lui servir à  afficher les médias et données.

L'idée est de stocker le fichier *.sqlite utilisé par la libraire ( ou son chemin local ) dans un managedObject du modèle de l'application.

En écrivant cela je me rend compte que le plus simple est de stocker le chemin local, sinon il faudra faire les lectures écritures entre la binaryData et le "disque", une vraie perte de temps !

FKDEV

D'où vient le .sqlite qui va être fourni à  la librairie, qui va le créer et en utilisant quel modèle  ?

pixman

Le fichier *.sqlite est le persistent store crée lors de l'utilisation de core data.

A priori ce fichier sera crée en back office et téléchargé par l'application hote ( comme un simple fichier ) l'appli hote se chargera de donner le chemin de ce fichier à  ma librairie ( qui est la seule à  possèder le modèle pour lire les infos )

Céroce

Tant que les deux fichiers sont créés avec le même modèle Core Data, je ne vois aucun inconvénient à  ta démarche.

pixman

Bonjour, c'est un peu ce que je me disait aussi !

Mais c'est toujours bon d'échanger, les retours d'expériences nous font avancer !