Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
GWT et l'architecture 3 tiers
Bonjour à tous,
Je suis débutante en GWT. Je voudrais faire une application web 3 tiers. Pour faire ça, on a l'habitude d'utiliser le modèle MVC selon J2EE (jsp, servlet et EJB). mais on m'a dit que gwt était plus intéressant et plus facile à utiliser.
ma question est: est-ce que avec gwt on peut faire une architecture 3 tiers et comment? sinon, est ce qu'il y a une autre alternative?
Je vous remercie d'avance pour votre aide.
Salut,
Une architecture 3tiers c'est pour moi 3 couches (web, métier, dao).
Le MVC lui ne s'applique qu'à la "partie" web (qui correspondrait à GWT). Je dirait donc oui on peut faire de l'architecture 3tiers avec GWT.
En espérant aider.
Il y a le pattern MVC (Modèle, Vue, Contrôleur) qui peut être appliqué à des composants ou a des applications.
Selon moi, il faut comprendre que le MVC, c'est du découplage de responsabilités : à chacun son job !
M, tu gères les données.
V, tu gères l'affichage des données.
C, tu contrôle les échanges entre M et V
Cela évite de faire tout n'importe où ...
Dans des composants GWT, comme SWT ou Swing d'ailleurs, on peut voir +/- ce pattern MVC mais c'est un autre sujet.
Si on parle de MVC appliqué à une application web, on peut voir le modèle en couche (3 tiers pour les adeptes des 3 couches / certains ont rajoutés d'autres couches pour d'autres niveaux de découplage) comme une application du pattern MVC à une web app :
- La couche accès aux données (Le modèle) : Les EJB.
- La couche présentation (La vue) : Les pages JSP réservées pour l'affichage.
- La couche métier (Le contrôleur) qui fait le lien entre les deux : Les servlets.
Ceci est ma vue personnelle car les séparations ne sont pas toujours nette :
Dans les EJB, il n'y a pas que des setters/getteurs, il y a aussi du code métier. Lorsque les EJB ne sont pas utilisés, on a fait de POJOS (couche DAO) et des classes métier qui manipulent ces POJOS (couche service)
Les servlets qui font le lien entre l'ihm web et les dao, c'est du code d'actions (qui souvent appellent les services métiers)
Dans le cadre d'application WEB, GWT s'attache principalement à la couche présentation (partie cliente de GWT). Les composants GWT te permettent de faire ta vue à la place des JSP.
Les services RPC peuvent être vus comme des contrôleurs qui font l'échange entre le client et le serveur. C'est par défaut des servlets et jouent donc le rôle dévolu au servlet dans l'architecture java 3 tiers classiques.
Une difficulté de GWT, c'est lorsqu'il faut faire transiter les POJOS java jusque dans la partie cliente. Ils doivent être convertible en javascript et là, il peut y avoir des difficultées (cf librairie GILEAD)
Merci beaucoup pour vos réponses,
Donc si je comprends bien, si on veut utiliser le modèle mvc pour trois couches, avec GWT, on aura:
- la partie vue : GWT
- la partie modèle: EJB
- la partie contrôleur: RPC
Tu peux te dire cela mais garde à l'esprit que les frontières ne sont pas aussi nettes : RPC, c'est du GWT. Et par EJB, je te conseillerai plutôt les EJB3 : Les simples Pojos et pas les anciens EJB2 (assez lourd).
Donc :
Modèle :
Ecris des POJO avec des annotations JDO ou JPA qui représentent tes entités (objets de ton modèle objet / beans correspondants aux tables de ta base).
Ecris une couche de service (appelons la couche domaine pour éviter la confusion avec les services RPC) indépendante de GWT (juste du métier) qui expose des méthodes métiers pour manipuler tes POJOS. Ex : un service de stock : StockService : add(Product p); remove(Product p); getProductById(int id), getProductBySupplier(int supplierId) . ...
Vue :
Composants GWT pour la vue. Je te conseillerai de créer des classes de vues (dérivant de composites) et c'est dans elle que tu va faire une hiérarchie de omposants GWT.
Contrôleur :
A cheval entre les deux :
Les interfaces des services RPC appelées à partir des composants GWT.
L'implémentation du service RPC qui appelle les services de ta couche domaine.
Remarques :
- Tes vues et tes interfaces de services RPC sont dans la partie cliente de GWT.
- Tes implémentations de services RPC et tes services (métiers) de domaine sont dans la partie serveur de GWT.
- Tes objets métiers (POJO / EJB) peuvent rester dans la partie serveur si ils ne transitent pas via le RPC sinon ils devront être dans la partie cliente.
Si tu as des problèmes à ce niveau, soit tu utilses un truc comme GILEAD, soit tu as des EJB côté serveur et leur équivalent côté client et il ta faut faire les transformations de l'un à l'autre ...- Si je te conseille de créer des services de ton domaine indépendant des services RPC de GWT, c'est pour te permettre de réutiliser tous tes règles et objets métiers indépendamment de ton ihm en GWT, par des WebService par exemple ou autre ...
Je ne voyais pas ça de manière aussi large. Pour moi le MVC ne s'appliquait qu'à la partie web (donc GWT) seulement, les couches métier et DAO n'en faisant pas partie.
Dans l'application sur laquelle je travaille c'est comme ça que j'ai appliqué le MVC ...
Les Vues sont les panels, windows etc de GWT (Ext-GWT en fait).
Les Models sont en quelques sortes les RPC (le serveur manipule les objets et me renvois ceux ci mis a jour).
Les Contrôleurs gèrent les Events et envoient les informations à qui de droit (Vues ou Services RPC).
Est ce 1 erreur de ma part que d'avoir vue les choses de cette façon ?
Non, ce n'est pas une erreur.
Pour moi, l'application, c'est l'ensemble (client + serveur) et j'applique ma vision du MVC dessus.
Mais on peut également voir l'application comme uniquement la partie cliente et en appliquant le MVC dessus, c'est ce que tu évoques.
Et si on applique le MVC uniquement à un composant GWT : Le M, ce sont les données du composant, Le V, son rendu et le C, les évènements de ce composant.
Certains ne seront peut être pas d'accord avec mon point de vue. De toute façon, l'important pour moi, c'est le découplage des responsabilités pour bien organiser son code et s'y retrouver plus facilement.
Merci beaucoup pour tous ces éclaircissements,
je commence à mieux percevoir les choses. en ce moment je travaille sur le tutoriel suivant: http://jl2tho.blogspot.com/2007/09/tutorial-gwt-g0.html
pour apprendre à manipuler GWT, et je crois que dans l'étape 6 de ce tutoriel (http://jl2tho.blogspot.com/2007/09/t...ur-gwt-g6.html) il est montré aussi comment utiliser l'accès aux données du serveur à travers un dao (dans l'exemple c'est la classe Compte qui implémente Serializable), donc je pense que ce sera un guide pour les EJB.
je ne l'ai pas encore testé, dès que j'aurais des résultats je vous le ferais savoir.
encore merci pour votre aide
Pour ceux que ça intéresse Google propose l'utilisation de l'architecture MVP
Modèle Vue Presenter qui est un cousin du MVC.
Il a de nombreux avantages et est assez facile à mettre en œuvre. Google propose d'ailleurs un documentation intéressante à ce sujet et un tutoriel avec un projet eclipse à télécharger
Pour plus d'information , je vous conseille : http://www.mikaelkrok.net/le-design-...1-introduction
Ce Tutoriel GWT implémente une architecture 3 tiers, je t'invite à t'en inspirer :
hugo.developpez.com/tutoriels/java/gwt/utilisation-gwt-avec-spring-et-hibernate/
Il est vrai que le M est sujet à discussions.Envoyé par benwit
En pratique, le limiter aux données de la Vue semble la meilleure pratique (surtout d'un point de vue découpage/"réutilisabilité"), le contrôleur servant à faire le lien entre M et couche Métier (elle même largement utilisée par d'autres composants de l'application).
Comme tu sembles avoir choisi GWT, je ne te propose pas JSF/Facelets/RichFaces/Seam/EJB3... à ben si, j'lai fait
@M€lK!oR
Très bien ce tutoriel, je ne connais GWT que depuis très récemment et je me demande quels sont les changements pour ce tutoriel par rapport à la nouvelle version notamment en ce qui concerne les remoteServices de GWT.
En tout cas j'ai très envi de m'y pencher dessus.
Il est très facile d'adapter ce tutoriel à GWT 2.0.
Il existe également un framework qui permet de faire du MVC en GWT, regarde du coté de Pure MVC.
De mon coté, je trouve le design pattern MVP beaucoup plus clair et plus facile à prendre en main. Surtout qu'avec GWT, l'introduction au MVP est déjà fait par Google.
Les explications de benwit sur les problématiques des couches d'une application sont très intéressantes et il a mis le point sur ce qui est important : le découplage de responsabilités.
J'aimerais ajouter mon commentaire sur ce poste afin d'éclaircir quelques points qui prêtes peut être à confusion.
L'architecture en couche et le modèle MVC ne sont pas la même chose. Même si ton approche à du vrai, elle risque d'entrainer un amalgame dans l'esprit de nos chers noobs
Le modèle MVC permet de découpler les responsabilités dans la couche de présentation. On peut l'utiliser avec GWT mais il est vrai que le modèle MVP est plus simple et apporte les mêmes avantages. MVP est donc conseillé.
En ce qui concerne les couches d'une application. Les 3 couches de bases sont :
1 - la couche de domaine (Pojo / JPA)
2 - la couche de service (Spring / Hibernate ou EJB3)
3 - la couche de présentation (GWT)
On parle souvent de N couches car on rajoute souvent des couches afin de découpler encore plus certains aspects d'architecture.
Pour revenir à GWT, je recommande de lire Programmation GWT 2 par Sami Jabber. Il y a un chapitre où il explique comment faire pour mapper directement les interfaces Rpc avec les interfaces des services Spring.
Les service Rpc ne sont rien d'autres que de la tuyauterie afin d'accéder aux services Spring (en général on utilise Spring, c'est pour ca que j'en parle comme ca). Il ne faut pas y mettre de code métier. On y mettra du code technique tel que la résolution des lazy loading avec l'API Gilead par exemple.
Précision sur les couches
La couche de domaine qui contient uniquement les Pojo va te permettre de créer facilement des diagrammes de classes qui vont représenter ton application (avec le plugin object-aid par exemple)
La couche de service va utiliser un DAO généric pour persister tes Pojos. On y trouveras les requetes Hql par exemple et des tests pour savoir si un Objet à le droit d'être persisté par exemple.
La couche de présentation c'est GWT. Pour moi la couche de présentation va de GWT.client jusqu'à GWT.server. GWT.server étant les appel Rpc côté serveur qui ne sont que de la tuyauterie.
Bonjour,
J'aime bien savoir plus de détails sur MVP et ses apports par rapport à MVC.
A vrai dire j'ai pas trouvé d'informations concrètes qui mettent en cause les de design pattern.
Est ce qu'il y a un tuto ou un article qui en parle.
Merci d'avance.
L'évènement déclencheur sur le pattern mvp associé à Gwt est la conférence donnée par Ray Rian au Google I/O de l'an dernier. "Best practice for architecting gwt apps"
Je te conseille de la regarder ou de lire la transcription ici : http://extgwt-mvp4g-gae.blogspot.com...practices.html
Tu apprendras pourquoi MVP est particulièrement bénéfique à GWT, notamment en ce qui concerne les tests qui peuvent être exécutés en pur java (et accessoirement avec des librairies de mock)
Répondre avec citation
Partager