J'ai une entité CoreData X et des contrôleurs pour cette entité, XController. Maintenant, il existe une autre entité, XGroup, contenant une collection d'entités X et un XGroupController.Problème de référence/conception cyclique du contrôleur de modèle
Maintenant, le problème est que XGroupController doit interagir avec XController, et il serait bien de passer XGroupController à un XGroup pour observer, puis obtenir les XControllers des entités X.
Donc la question est: est-ce une bonne idée de stocker une référence (faible, pour éviter les cycles de retenue) à un contrôleur dans une entité? C'est juste un peu "faux". Y at-il un autre modèle de conception pour cela? [Edit] Quelques informations supplémentaires: XController/XGroupController sont des contrôleurs de vue; et la raison pour laquelle il s'est senti "mal" est que la couche de vue ne devrait pas être dans la couche du modèle. Donc @TechZen a raison avec son premier paragraphe.
Cependant, comment ferais-je cela si je n'avais pas cette référence? La façon dont je vois est de passer XGroupController tous les XControllers existants (plus les mettre à jour quand ils changent), et puis quand les éléments dans le groupe X changent, trouver les contrôleurs correspondants (en vérifiant si la propriété XControllers pour son entité X est dans le XGroup) et enfin parler aux XControllers.
Je dois encore travailler pour des choses que le modèle gère déjà très bien. Cela ne rendra-t-il pas inutile la couche du modèle si je dois gérer des groupes dans la couche contrôleur une autre fois?
La différence qui fait en termes de Loc/complexité est tellement importante, ai-je oublié quelque chose? (Peut-être devrais-je ajouter que dans mon scénario, il n'est pas logique de stocker les informations que XGroupController doit donner à XController via le modèle).