Quelle est votre recommandation pour l’architecture des applications GWT? MVC, MVP ou solution de messagerie personnalisée?

Question

Je viens de commencer un nouveau projet GWT pour un client et je suis intéressé par l'expérience des gens avec différentes architectures GWT MVC. Sur un projet récent, j’ai utilisé GXT MVC , ainsi qu'une solution de messagerie personnalisée (basée sur MQ d'Appcelerator ). GXT MVC fonctionnait correctement, mais cela semblait excessif pour GWT et il était difficile de faire fonctionner l’historique du navigateur. J'ai entendu parler de PureMVC et GWTiger , mais ne les a jamais utilisés. Notre solution MQ personnalisée fonctionnait plutôt bien, mais il était difficile de tester des composants avec JUnit.

De plus, j'ai entendu dire que Google Wave (une application GWT) est écrit à l'aide d'un modèle Model-View-Presenter. Un exemple d'application MVP a récemment été publié, mais le code ne le permet pas. semble pas si intuitif.

Si vous construisiez une nouvelle application GWT, quelle architecture utiliseriez-vous? Quels sont les avantages et les inconvénients de votre choix?

Merci,

Matt

Answer 1

Il est intéressant de noter que Google a finalement écrit un tutoriel pour la conception utilisant l’architecture MVP. Il clarifie de nombreux éléments de la conversation google i / o énumérés ci-dessus. Prenez un coup d'oeil: https://developers.google.com/web-toolkit/articles / mvp-architecture

Answer 2

Je suis heureux que cette question ait été posée, car GWT desperatley a besoin d’une méthode de structuration des applications semblable à celle des rails. Une approche simple basée sur les meilleures pratiques qui fonctionnera pour 90% de tous les cas d’utilisation et permettra une testabilité extrêmement facile.

Ces dernières années, j’utilisais ma propre implémentation de MVP avec une vision très passive qui s’asservissait à tout ce que le présentateur lui disait de faire.

Ma solution était la suivante:

• une interface par widget définissant les méthodes de contrôle de l'aspect visuel
• une classe d'implémentation pouvant être un composite ou utiliser une bibliothèque de widgets externe
• un présentateur central pour un écran qui héberge N vues composées de M widgets
• un modèle central par écran contenant les données associées à l'aspect visuel actuel
• classes d'écoute génériques telles que "SourcesAddEvents [CustomerDTO]" " (l’éditeur n’aime pas les vrais symboles des génériques java ici, j’ai donc utilisé les crochets), car sinon vous aurez beaucoup des mêmes interfaces qui diffèrent simplement par le type

Les vues obtiennent une référence au présentateur en tant que paramètre constructeur, ce qui leur permet d'initialiser leurs événements avec le présentateur. Le présentateur gérera ces événements et notifiera les autres widgets / vues et / ou appellera gwt-rpc qui, en cas de succès, place son résultat dans le modèle. Le modèle a une valeur typique "Property [List [String]]" = = " mécanisme d’écoute de changement de propriété enregistré auprès du présentateur afin que la mise à jour d’un modèle par une requête gwt-rpc aille à tous les affichages / widgets intéressés.

Avec cette approche, la testabilité a été très facile avec EasyMock pour mes interfaces AsynInterfaces. J'ai également eu la possibilité d'échanger facilement l'implémentation d'une vue / d'un widget, car tout ce que je devais réécrire était le code qui avisait le présentateur de certains événements, quel que soit le widget sous-jacent (Button, Links, etc.).

Problèmes liés à mon approche:

• Ma mise en œuvre actuelle rend difficile la synchronisation des valeurs de données entre les modèles centraux de différents écrans. Supposons que vous avez un écran qui affiche un ensemble de catégories et un autre écran qui vous permet d’ajouter / éditer ces éléments. Actuellement, il est très difficile de propager ces événements de changement à travers les limites des écrans, car les valeurs sont mises en cache dans ces modèles et il est difficile de savoir si certaines choses sont sales (cela aurait été facile avec un Web1.0-html traditionnel type de scénario -dumb-terminal avec la mise en cache déclarative côté serveur).
• Les paramètres de constructeur des vues permettent d'effectuer des tests très simples, mais sans un cadre d'injection de dépendances solide, on disposera d'un code de configuration / usine UGLY dans "onModuleLoad ()". Au moment où j'ai commencé, je ne connaissais pas Google GIN. Par conséquent, lorsque je restructurerai mon application, je l'utiliserai pour supprimer ce passe-partout. Un exemple intéressant ici est le " HigherLower " jeu à l'intérieur du GIN-Trunk.
• Je n'ai pas bien compris l'historique la première fois. Il est donc difficile de naviguer d'une partie de mon application à une autre. Mon approche n’est pas consciente de l’histoire, qui est un grave ralentissement.

Mes solutions à ces problèmes:

• Utilisez GIN pour supprimer les problèmes d'installation difficiles à gérer
• Tout en passant de Gwt-Ext à GXT, utilisez son framework MVC comme EventBus pour attacher / détacher des écrans modulaires afin d'éviter les problèmes de mise en cache / synchronisation
• Pensez à une sorte d’abstraction de "Place" telle que décrite par Ray Ryan dans son exposé à I / O 09, qui jette un pont sur l’écart entre GXT-MVC et l’approche GWTs-Hitory
• Utilisez MVP pour les widgets pour isoler l'accès aux données

Résumé:

Je ne pense pas que l'on puisse utiliser un seul " MVP " approche pour une application entière. Il faut absolument un historique pour la navigation dans les applications, un bus d’événement tel que GXT-MVC pour attacher / détacher des écrans, et MVP pour permettre de tester facilement

Answer 3

Voici une présentation récente de Google IO sur la architecture de votre application GWT .

Profitez.

-JP

Answer 4

Si vous souhaitez utiliser l'architecture MVP, jetez un coup d'œil à GWTP: http://code.google.com/p/gwt-platform/ . Je travaille sur un framework MVP open source, qui supporte de nombreuses fonctionnalités intéressantes de GWT, notamment le fractionnement de code et la gestion de l'historique, avec une simple API basée sur des annotations. Il est assez récent, mais est déjà utilisé dans un certain nombre de projets.

Answer 5

Vous devriez consulter les portlets GWT . Nous avons développé GWT Portlets Framework tout en travaillant sur une application de portail RH de grande taille. Il est désormais gratuit et à source ouverte. Sur le site Web de GWT Portlets (hébergé sur le code Google):

Le modèle de programmation est un peu similaire à l'écriture de portlets JSR168 pour un serveur de portail (Liferay, JBoss Portal, etc.). Le " portail " votre application est-elle construite en utilisant la structure de portlets GWT en tant que bibliothèque? Les fonctionnalités de l’application sont développées sous forme de portlets à couplage faible, chacun avec un fournisseur de données optionnel côté serveur.

Chaque portlet sait comment externaliser son état dans une sous-classe sérialisable de PortletFactory (modèle momento / DTO / factory) permettant ainsi des fonctionnalités importantes:

• Les opérations CRUD sont gérées par un seul RPC GWT pour tous les portlets
• La disposition des portlets sur une " page " peut être représenté comme une arborescence de WidgetFactory (une interface implémentée par PortletFactory)
• Les arbres de WidgetFactory peuvent être sérialisés et redirigés vers / à partir de XML sur le serveur, pour stocker les dispositions d'interface graphique (ou "pages") dans des fichiers de page XML

Les autres fonctionnalités importantes du cadre sont répertoriées ci-dessous:

• Les pages peuvent être éditées dans le navigateur au moment de l'exécution (par les développeurs et / ou les utilisateurs) à l'aide de l'éditeur de disposition de structure
• Les portlets sont positionnés de manière absolue pour pouvoir utiliser les régions de défilement
• Les portlets sont configurables. Indiquent quand ils sont en train de charger le chargement automatique. "Chargement spinner". afficher et peut être maximisé
• Des widgets thématiques comprenant une boîte de dialogue stylée, un bouton de remplacement de style CSS, de petites touches d'outils et un menu basé sur des modèles HTML

Les portlets GWT sont implémentés dans le code Java et n’enveloppent aucune bibliothèque Javascript externe. Il n’impose aucune infrastructure côté serveur (par exemple, Spring ou J2EE), mais il est conçu pour fonctionner correctement avec ces infrastructures.