Discussion :

[cuddles80]

Bonjour,

Je met en place le design pattern command pour l'accès à mes services RPC.

Actuellement pour chaque commande, tout fonctionne avec un callback et deux méthodes classiques en cas de succès et d'erreur (la même chose que ce que propose GWT pour l'appel aux services RPC par défaut).

je me demande si il ne serait pas mieux de propager un événement a la place de faire appel à la méthode d'un callback.

plutôt que d'avoir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
dispatch.execute(mon_action,new AsyncCallback(LeRetour){
    public void success....
    public void fail....
});

de faire un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
dispatch.execute(mon_action);
EventBus.addListener(LeRetourEvent);

Ce que je vois comme avantage c'est par exemple:
si un module de mon interface décide de mettre a jour une entité, sa mise à jour propagerai un évènement du genre EntitéMiseAJour ce qui permettrai à d'autres modules de tenir compte de cette action.
(je pense aussi que cela permet d'avoir un couplage plus faible non ?)

En fait ce que j'aimerai savoir c'est si cela s'inscrit dans "les bonnes pratiques" de GWT et si d'autres personnes procède comme cela,

Merci

[spikie]

Bonjour,

Alors j'ai regardé la conf IO de google a propos de GWT.

Et c'est ce qu'il fait pour ses services RPC Et oui c'est une bonne pratique!

ps : [nomedia="http://www.youtube.com/watch?v=PDuhR18-EdM"]YouTube- Google I/O 2009 - Best Practices for Architecting GWT App[/nomedia]

[kenji_getpowered]

Salut,

Effectivement c'est une bonne pratique, Google met en avant ce concept d'eventbus. Je ne peux que te conseiller cette page pour bien comprendre le lien de l'event bus dans une architecture MVP
http://www.mikaelkrok.net/le-design-...-mvp-en-detail
Google fournit un exemple de projet qui permet de bien comprendre le tout.