Je vous conseille avant tout de lire l'introduction http://www.mikaelkrok.net/le-design-pattern-mvp-et-gwt-1-introduction
Commençons par le diagramme du MVP
Je remercie l'auteur pour nous faire partager son travail.
Le diagramme semble complexe à première vue mais si on découpe chaque interaction ou ensemble d'interaction entre couches on peut facilement arriver à comprendre leur dialogue. Il y a un point sur lequel je ne suis pas d'accord néanmoins et je vous invite à me donner votre avis. L'auteur du diagramme indique que le presenter et la vue sont instantiés par l'AppController. c'est vrai dans le cas de l'application exemple de google, mais on remarque assez vite qu'on sera bloqué si tout doit passer par l'AppController. Adieu les boite de dialogue ajax car si on doit passer par l'appController on a plus la main sur le Presenter qui est en cours. On s''aperçoit vite qu'un Presenter peut être instantié dans n'importe quel autre Presenter si on en a besoins.
Astuce :
Le presenter a une méthode go(Container c) qui lui permet de se dessiner lui même dans ce container. Il suffit donc d'instancier le Presenter et la Vue dans le Présenter actuel (par éxemple après le clic sur le bouton) et de lui passer en paramêtre une fenêtre de dialogue ou tout autre panel et le tour est joué.
Le cheminement du MVP (diagramme de séquence)
C'est un simple diagramme qui s'inspire fortement du diagramme de séquence. Je l'ai réalisé pour m'aider à mieux comprendre le cheminement du MVP.
En français :
Le Presenter fournit une interface (un contrat) à la View qui lui indiquera quelles références il a besoin et comment les donner - Interface Declaration. La View s'engage alors à retourner les références y compris la sienne et créé l'interface graphique (y compris évènement) - Object References.
Le Présenter associe les évènements provenant de la vue à des actions ( méthode bind() ) - Bind References
Quand un évènement survient en provenance de la vue, plusieurs choix s'offrent au programmeur :
- Lancer l'évènement dans l'EventBus (à qui on a associé une action dans l'AppController)
- Appeler la couche modèle à travers un service
- Ou réaliser tout autre type d'action (calcul, graphique, etc...)
- Ou bien encore une combinaison de ces éléments
Pour finir, il peut choisir de rafrachir la View (par exemple mettre à jour les données).
Voila, j'espère que j'ai été clair et que mon humble schéma vous aura permis de mieux cerner le modèle MVP.
Pour continuer :
Des exemples de développement
- http://reminiscential.wordpress.com/2010/03/01/building-a-gaegwt-application-using-the-best-practices-index/
- http://borglin.net/gwt-project/?page_id=10
- code.google.com/p/gwt-mvp-sample/
Comments
L'explosion de l'appcontroller est le problème que je rencontre également. En fait, on peut traiter un action sans passer par l'appControlller. En effet, dès que l'event est déclenché on le capte et éventuellement on le traite dans le presenter en cours. C'est ce dont je parle dans l'article http://mikaelkrok.net/le-design-pattern-mvp-et-gwt-3-exemple-de-liens-entre-presenters. Il n'y a pas de souci car l'eventbus est constamment partagé. Par contre la seule classe qui gère l'history et les tags (#anchor) est l'appController. Peu importe si les autres presenter implémentent l'interface ValueChanged. Du coup, il m'est impossible de correctement gérer l'historique. Pour conclure, je n'ai pas encore trouvé de moyens qui soient assez efficaces pour tout gérer comme si il n'y avait QUE l'appController. Toute idée est bonne à prendre ! --- Désolé pour la longueur ;) ---
Tout d'abords felicitations pour le blog le sujet est bien expliqué !
Je pense avoir compris le pattern,mais je me pose des questions sur l'implementation :
Sur une application de grande taille, on aura une multitude de presenters : tout lister dans le AppController n'est pas tres maintenable si ?
Quelle est la meilleure maniere de proceder selon toi ? La division en differents modules fonctionnels ne pose pas de problemes de communication avec l'event bus ?
Dans le cadre de mon stage de fin d'etudes (debute il y a 2 semaines) je decouvre GWT et je suis impressionne par la puissance du framework. En ce moment j'etudie l'architecture MVP et les eventBus. Le blog tombe donc a point nomme. Je vous avouerai quand meme que c'est a ce jour le plus grand obstacle auquel j'ai ete confronte, et meme apres 11h d'etudes sur ce pattern je suis toujours en eaux troubles, meme si le blog m'a bien aide.
Il me tarde donc de decouvrir la suite des billets pour en apprendre plus sur le MVP.
Bonne continuation ;)
J'ai prévu 2 ou 3 trucs encore. J'ai fais une pause à mon taff sur GWT. Lorsque je reprendrai j'aurai l'occasion d'écrire de nouveaux billets.
Juste un petit commentaire pour t'encourager à écrire d'autre billet sur GWT.
Bonne continuation
Avec cette méthode ce qui est intéressant est de créer toutes les vue indépendamment ce qui permet de les tester puis on peut les appeler quand on veut.
RSS feed for comments to this post.