Motif de vue passive: communication entre les composants

Question

Je traite chaque triade MVP comme un composant isolé. Avec la vue implémente une interface IView par exemple, le présentateur ne connait bien que la vue via IView bien sûr. C'est ce que je peux rendre le composant aussi réutilisable que possible. Maintenant, je dois combiner ces composants MVP pour former une application. Je me demande quelle est la bonne pratique pour garder ces composants aussi séparés que possible. Mais bien sûr, je devrais les faire communiquer/réagir les uns aux autres. Puis-je simplement exposer IView aux présentateurs de l'autre? Ou devrais-je simplement laisser les présentateurs communiquer entre eux sans connaître les vues sous-jacentes?

Merci

Answer 1

En MVP je vois les présentateurs comme les orchestrateurs d'activité. En tant que tels, ils sont le choix naturel sur lequel baser la composition d'une application.

Exposer la vue d'un présentateur à d'autres présentateurs rompt l'idée d'encapsulation dans le modèle MVP. Bien que cela ne réduise pas la réutilisabilité du composant en exposant sa vue, cela réduit la réutilisabilité d'un composant en utilisant la vue d'un autre composant car cela augmente les dépendances des composants. Donc, je garderais les vues privées pour les présentateurs et je laisserais seulement les présentateurs communiquer les uns avec les autres.

---

Elaboration en réponse au commentaire

Quand je dis garder la vue privée au présentateur, je veux dire privé: non exposée au monde extérieur que par la médiation du présentateur. Bien sûr, le présentateur peut exposer des méthodes au monde extérieur qui l'amènera à manipuler sa vue. Si le présentateur le fait via une interface, il peut en fait utiliser sa propre vue en tant que délégué pour l'implémentation de l'interface, mais - contrairement à ce que vous proposez - le présentateur délègue des choses à la vue et non l'inverse. En procédant de cette manière, vous garantissez, ou du moins vous avez plus de chances que toute la logique d'interaction reste dans les présentateurs et ne se retrouve pas dans les présentateurs et les vues.

Une vue doit uniquement être manipulée par son présentateur. Maintenant, bien sûr, vous pouvez réutiliser les vues dans plusieurs présentateurs, mais l'instance d'une vue ne doit être manipulée que par le présentateur qui l'instancie. Si vous l'exposez directement (même à travers des interfaces entières ou partielles), vous commencez à devoir gérer une vue qui peut être manipulée par plusieurs animateurs et aucun présentateur ne contrôle plus la vue.

Le seul code que j'ai dans la vue sont les notifications à son présentateur de ce qu'un utilisateur a fait (également connu sous le nom de gestes de l'utilisateur dans certaines discussions MVP). C'est au présentateur de décider quoi faire à ce sujet. Je garde également toute la logique concernant les contrôles à activer/désactiver en réponse aux sélections de l'utilisateur dans le présentateur et non dans la vue. Cela permet non seulement de conserver toute la logique d'interaction dans le présentateur, mais également de créer des interfaces utilisateur (formulaires) testables à l'unité.

Answer 2

Une bonne pratique pour orchestrer les présentateurs consiste à utiliser un bus d'événements. les présentateurs s'inscrivent au bus et écoutent les événements auxquels ils doivent réagir. d'autres présentateurs jettent des événements sur le bus pour permettre aux cibles possibles de savoir ce que vient de faire. Les messages doivent être basés sur le domaine du problème, et non technique (par exemple "produit 123 créé")

un good example est l'architecture mvp GWT et the newer version.