Retour : Page Principale > sommaire applications >  applications GWT

---

Point sur l'architecture d'une application GWT

Rédacteur : JeanPascalMilcent
Date de rédaction : 15 juin 2010
État : brouillon

Depuis juin 2009, de nombreux articles ont été écris sur l'architecture des applications GWT. Dans le même temps, les applications COEL et CEL ont été développées par l'équipe de Tela Botanica.
Bien qu'ayant utilisé une architecture MVM (Modèle-Vue-Médiateur) très proche du modèle MVP (proposé par Google), nous avons rencontré quelques difficultés.
Cet article propose de faire une synthèse des articles disponibles sur l'architecture d'application GWT afin de résoudre les points de blocage rencontrés dans la réalisation de COEL et CEL.

Les articles consultés

Liste d'articles concernant GWT, l'architecture d'application et l'utilisation de GXT dans le cadre d'application MVP :
http://delicious.com/jp_milcent/architecture+gwt

Les problèmes rencontrés

Problèmes à résoudre :

• Imbrication dans les vues de la gestion des évènements et de la création des interfaces
• Gestion des retours des appels asynchrones trop éloignés des vues
• le rôle de la classe Modele est mal défini
• Imbrication très forte de GXT dans COEL
• Difficulté a mettre en place des Tests (pas de recul sur l'architecture de l'appli, Java, GWT, GXT...)
• Imbrication des modèles dans les vues
• Difficulté à paginer les résultats
• Services Web REST pas tous uniforme au niveau de leur fonctionnement

Problèmes en partie résolue :

• Difficultés à chaîner proprement les appels asynchrones => utilisation d'un Sequenceur
• Classes contenant trop de méthodes => difficulté à lire le code => Début séparation du code en fonction des vues (ex. Collection)

Propositions de solutions

Imbrication dans les vues de la gestion des évènements et de la création des interfaces
L'architecture MVM est un début mais il manque une couche supplémentaire au niveau des vues. Dans l'architecture MVP de Google les classes Presenter assurent la gestion des évènements des vues auxquelles elles sont liées.
Cela me semble une bonne solution pour diminuer la taille des Vues (trop de méthodes) et pour améliorer la gestion des évènements.

Imbrication très forte de GXT dans COEL

Arborescence

Arborescence actuelle de COEL

• client
  • composants : un package par composant qui contient son arborescence. Un composant est un élément graphique qui peut être réutilisé à plusieurs endroits dans les vues de l'application.
    • composant1
    • composant2...
  • configuration : contient les classes représentant les fichiers js de configuration de l'application (voir /war/config/...).
  • i18n : contient les classes de fichiers .properties d'internationalisation de l'application
  • images : contient les icônes de l'application
  • interfaces : contient les fichiers servant d'interfaces aux classes de l'application
  • modeles : contient les classes représentant les objets métiers de l'application et les classes DAO asynchrones.
  • synchronisation : contient le séquenceur.
  • util : ensemble de classes utilitaires (pas de composant graphique)
  • vues : contient les vues de l'application
  • Mediateur.java : l'équivalant du fichier  AppControler
  • Modele.java : sert de Façade à l'ensemble des fichiers DAO Asynch.
  •  MonAppli.java : fichier principal de l'appli.

Proposition d'arborescence

• client
  • bibliotheque
    • interfaces : contient les fichiers servant d'interfaces aux classes de l'application
    • synchronisation : contient le séquenceur.
    • util : ensemble de classes utilitaires (pas de composant graphique)
  • composants : un package par composant qui contient son arborescence. Un composant est un élément graphique qui peut être réutilisé à plusieurs endroits dans les vues de l'application.
    • composant1
    • composant2...
  • configuration : contient les classes représentant les fichiers js de configuration de l'application (voir /war/config/...).
    • i18n : contient les classes de fichiers .properties d'internationalisation de l'application
  • modeles : contient les classes représentant les objets métiers de l'application et les classes DAO asynchrones.
  • presenteurs : contient les classes présentateurs liées au vues.
  • vues : contient les vues de l'application
    • images : contient les icônes de l'application
  • Mediateur.java : l'équivalant du fichier  AppControler
  • Modele.java : sert de Façade à l'ensemble des fichiers DAO Asynch.
  •  MonAppli.java : fichier principal de l'appli.

---