Communication intercomposant dans une vue (MVC)

Question

Quelles sont les meilleures pratiques pour orchestrer l'interaction entre des composants complexes présents dans votre vue? Je ne parle pas de simples widgets comme une zone de liste déroulante ou un contrôle de grille, mais de composants qui sont constitués de plusieurs widgets et qui peuvent mériter d'être testés individuellement.

Souhaitez-vous:

1. Définir les interfaces abstraites pour chaque composant, laisser le contrôleur les raccorder par injection de dépendance pour les laisser parler directement entre eux par des appels de méthode? Les composants sont donc conscients des interfaces des autres composants.
2. Définir les événements que chaque composant peut déclencher et permettent au contrôleur de les connecter directement via des écouteurs d'événement les uns aux autres? Les composants ont donc des gestionnaires d'événements attachés aux récepteurs d'événements d'autres composants.
3. Définir des interfaces abstraites pour chaque composant, définir les événements qu'elles peuvent déclencher et laisser le contrôleur écouter sur tous les événements et effectuer des appels de méthode sur les interfaces? Les composants sont donc complètement agnostiques vis-à-vis des autres composants.
4. Une application classique du modèle Observer?
5. Autre chose?

Mise à jour: J'ai coup sur « laisser le contrôleur ... » de # 1-3 parce qu'il est pas nécessairement le contrôleur qui doit faire le routage/orchestration dans ces cas. Ce pourrait être la vue elle-même.

J'ai adopté la méthode # 3 dans un projet récent et j'étais content du découplage et de la testabilité individuelle des composants. Cependant, j'ai le sentiment que je pourrais rationaliser le câblage des composants. Dans mon cas, l'objet View principal doit ajouter plusieurs écouteurs d'événement sur chaque composant, puis appeler des méthodes sur les composants appropriés, après avoir parfois effectué un traitement local (comme parler avec le modèle). Le code pour ajouter les gestionnaires d'événements semble un peu brouillon et je suis particulièrement à la recherche d'un moyen propre de le faire.

Answer 1

L'option 3 ressemble au modèle Mediator et constitue souvent la meilleure approche lorsque la logique de mise à jour et la communication entre les objets sont complexes. Cela a aussi l'avantage de garder centralisée la logique de contrôle et l'initialisation, ce qui facilite le traçage et le débogage de ces types de cas.

Answer 2

On dirait que vous avez les connaissances pour répondre à votre propre question sur celui-ci, mais peut-être juste manquer de la confiance pour plonger po Êtes-vous juste explorer ou êtes-vous coincé quelque part?

Je voudrais ajouter qu'une chose supplémentaire que vous pouvez faire est de placer un gestionnaire de composants entre tous les objets pour faciliter la communication. Dans le passé, quand j'avais fait quelque chose de similaire, l'objet de gestion finissait par prendre des données de chaque composant, fusionnant les données ensemble, et les transmettant au modèle comme une grosse requête. Chacun de mes composants avait un délégué à appeler et transmettait des données, et bien sûr l'implémentation de ce délégué était sur mon gestionnaire de composants. Je laisse aussi cet objet manager agir comme un proxy au réseau J'attendais que la complexité soit plus élevée avant d'adhérer à SRP et ai fait de cette responsabilité sa propre classe.

Fondamentalement tout ce que vous avez dit sonne bien. Je recommande de simplement plonger et explorer.