›

Question d'architecture sur Core Data et des entités "en arbre"

colas_colas_ Membre
dans Objective-C, Swift, C, C++ #1

Bonjour,


 

je voudrais vous exposer une question de design/architecture à  laquelle je suis confronté, l'erreur que j'ai faite et la solution que j'ai finalement choisie. Tout commentaire est le bienvenu !

 

J'ai un modèle Core Data. Des fiches de cuisine.

Chaque fiche cuisine a une liste d'ingrédients.

Les ingrédients sont eux-mêmes " structurés ". Par là , j'entends que " légume " est un ingrédient et que " tomate " aussi et que " tomate cerise ". Bref, les ingrédients admettent des sous-ingrédients.

 

Mon problème est de comment organiser cela.

 

 

 

1ère méthode : 100% Core Data

"""""""""""""""

 

Je crée une entité " Ingrédient " qui a une relationship (multiple) `subIngredients` et un attribut `name`.

Exemple : 

 




Entity `Legume`

- name : "Légume"

- subIngredients : < `Tomate`, `Courge` >



Entity `Tomate`

- name : "Tomate"

- subIngredients : < `Tomate cerise`, `Tomate coe“ur de boe“uf`, `Tomate noire` >





etc.


 

L'entité FicheDeCuisine a une relationship (multiple, ordered) `ingredients`.

 

Avantage : c'est du 100% Core Data (fetch des fiches de cuisine qui ont des tomates est assez facile)

Inconvénients (constaté lors de l'usage) : 


  • si l'on veut changer la structure des ingrédient, c'est assez galère.
  • les ingrédients doivent être préchargés avant la création d'un nouveau document (un document est un ensemble de fiches de cuisine). C'est assez galère à  gérer pour les transition de modèle
  • avec ce modèle, je peux me retrouver (si je m'y suis mal pris) avec deux Ingredient `Tomate`.
 


 

2è méthode : 50% Core Data, 50% artisanal

""""""""""""""""""""

 

C'est la nouvelle archi à  laquelle j'ai pensé. Je poste ce message alors que je suis en train de l'implémenter pour éventuellement faire mieux !!!

 

Je ne gère plus les ingrédients avec Core Data.

 

En gros, je vais adjoindre à  ma base sql un document texte qui ressemble à  

 




#######################################

#######################################

*** Légumes :



- Tomates

-- Tomates cerise

-- Tomates coe“ur de boe“uf

-- Tomates noires





- Courges

-- Courgettes

-- Courgettes rondes





#######################################

#######################################

*** Viande :



- Poulet

-- Blancs de poulet

-- Cuisse de poulet



- Porc

-- Charcuterie

--- Saucisson

--- Andouillette

--- Chorizo

-- Côtes de porc



- Agneau



- Boe“uf


 

C'est ce document qui code la " structure " en arbre de mes ingrédients.

 

Ensuite, pour les fiches de cuisine, je vais leur donner un attribut de type transformable qui sera un array de strings. Ces strings seront des noms d'aliment. Pour connaà®tre les " sous-ingrédient " d'un aliment donné, on partira du nom (" tomate ") et on interroge le fichier texte qui code la structure (plus exactement, on interrogera un objet crée à  partir du fichier texte ; cet objet est aussi capable de modifier la structure est de re-créer un fichier texte)

 

Avantages : souple, léger, migrations plus faciles

Inconvénients : 


  • pas très objet
  • mon parseur est fait maison (parce que je veux qu'une liste d'ingrédients soit facile à  écrire) et si mes besoins évoluent... ça risque d'être embêtant.
  • je n'ai encore jamais utilisé les transformable... je ne sais pas trop ce que ça vaut !
  • il faut gérer les auxiliary data pour sauvegarder la structure (dans le mode 100% core data, c'était sauvegardé dans le sql)
 


J'ai déjà  écrit le parseur et la classe qui gère la structure. Il ne me reste plus qu'à  intégrer cette logique dans mon appli.

 

Pour ceux que ça intéresse, je mets en pièce jointe le couple de classes qui gère le parsing et qui matérialise ces objets "en arbre".

 

Et vous comment auriez-vous fait ?

 

 

 

 

Bon appétit !

 

Colas

Réponses

Connectez-vous ou Inscrivez-vous pour répondre.