Utilisation de GWT/Hibernate et validation

[Vincent Ferries]

Bonjour à vous,

Je sollicite ici d'éventuels utilisateurs de GWT au sujet de questions que j'estime "de fond" sur cette technologie là.

Mon principal souci provient de la lourdeur de mise en place d'écrans simples type CRUD sur une application.

La partie persistence est gérée au moyen d'Hibernate. Les principales méthodes sur ces objets métier sont implémentées dans des DAOs, eux-même appelés depuis des services.

GWT "impose" l'utilisation de DTO (par défaut il ne permet pas de transférer des entités Hibernate). Ce qui fait que mes services, en plus d'appeler les méthodes des DAOs, ont aussi à charge de transformer mes objets métier en DTOs et inversement.

J'en viens alors à mes questions :

- Utilisez vous effectivement toutes ces couches? Préconisez vous d'utiliser des technos telles que Gilead, GWT-Platform, Dozer pour éviter ces désagréments? Selon vous est-il plus intéressant de partir sur une approche RequestFactory (model centric) qui me semble plus proche de la philosophie adoptée par Play! notamment? En connaissez vous d'autres qui soient utilisables?

- Quid de la validation des données soumises? N'existe-t-il pas de mécanisme propre pour ce faire (type JSR303 par exemple)? Doit-on faire porter dans ce cas les annotations de validation sur les DTOs?

Merci d'avance.

Vincent FERRIES

[Olivier Rossel]

Les TO sont là pour couper dans la masse d'une entity (avec son
cortège de collections
de sous-objets) avant de l'envoyer.
Les BO sont là lorsque les TO et ton modèle de base ne correspondent
pas franchement.
La séparation par couches, à mon sens, permet de ne pas s'emmêler les
pinceaux dans la politique de
tests de l'appli. Ca permet aussi de mieux naviguer dans le code,
quand on débarque sur une appli.

Si tu n'as aucune des problématiques citées, tu peux foncer à la
bourrin, PHP-style.



2012/4/25 Vincent Ferries <vincent...@gmail.com>:

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes Toulouse JUG.
> Pour envoyer un message à ce groupe, adressez un e-mail
> à toulou...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> toulouse-jug...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/toulouse-jug?hl=fr

[Ludovic Borie]

Pour faire du CRUD très simple, moi j'ai tendance à utiliser ce que GWT propose en natif, c'est à dire les Editor
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiEditors
En gros pour un formulaire tu vas créer un SimpleBeanEditorDriver qui te permettra de mapper ton UI et ton TO
Le code est simple, et vraiment lisible, par exemple couplé à une interface avec UIBinder.
Un exemple de formulaire : https://github.com/lauterry/OpenDataWiki/blob/master/src/com/sfeir/odw/client/ui/EditCommuneViewImpl.java

Mais si la question c'est : est ce qu'on ne ferait pas mieux de faire autrement que d'utiliser cette couche UIBinder / Editor / RPC / DAO / Hibernate pour sauver un malheureux Bean, je dirais que ça pourrait être sujet à troll... C'est vrai que vu comme ça, c'est quand même très "old school". Comme l'a dit Olivier, c'est une question de complexité finale et de besoin. Pour une compréhension sur le long terme, je trouve le découpage plus simple, mais ce n'est que mon avis.

[Olivier Rossel]

L'éditeur générique dont tu parles, Ludovic, a l'air diablement intéressant.
J'extraie la phrase qui me plait particulièrement:
"Data stored in an object graph [are] mapped onto a graph of Editors"

Exactement un besoin que j'ai en ce moment en Swing.
Si qq'un connait donc une bibliothèque qui ferait çà en Swing,
je suis very *very* preneur.


2012/4/25 Ludovic Borie <l.b...@gmail.com>:

[Romain MOUTON]

Pour revenir au sujet de Vincent, J'ai été confronté à la même problématique avec GWT/Hibernate.
Étant donné que nous ne pouvons/voulons pas faire transiter un bean complexe d'Hibernate coté client nous sommes partis sur Gilead.

Nous avons donc mappé, (dans une couche métier supplémentaire) les infos dans un bean "light" à faire transiter coté client. La sérialisation est assez rapide ensuite et les objets assez légers.

Par contre attention au objets de type Clob/Blob trop volumineux qui peuvent vite faire exploser un navigateur :)

Par contre c'est vrai que c'est assez verbeux comme approche Hibernate -> Daos -> services -> Mapping bean/lightbean -> RPC -> UI
Mais comme l'a dit Olivier, on s’emmêle moins les pinceaux :)

Romain

2012/4/25 Olivier Rossel <olivier...@gmail.com>

[Bruno Marchesson]

Bonsoir à tous,

Avec Gilead, on peut éviter d'envoyer des Clob/Blob en utilisant l'annotation @ServerOnly : le champs est alors remplacé par null et pas envoyé coté client (ça sert aussi à ne pas envoyer les mots de passe sur la couche GWT sans créer un DTO).

Par contre, puisque j'en suis l'auteur, je peux vous dire que la lib n'est plus maintenue depuis plus de deux ans (j'ai passé le statut à "inactif" sur SourceForge). Elle est donc fonctionnelle, mais rien ne garantit qu'elle fonctionne avec les versions d'Hibernate > 3.5.

Bruno

[Nicolas Zozol]

C'est un peu le souci de GWT, qui plonge dans le anemic-domain-model puisque les capacités du domaine sont rarement possibles côté client.
Les DTO et compagnies ne vont pas forcement dans le sens de l'histoire.
On en parlait déjà avec la version 1.6 : une annotation @DoNotCompile dans un objet domain resolverait ce soucis. Après tout, le compilateur devrait faire ce qu'on lui dit de faire.
J'avais essayé de faire de l'injection selon que l'on soit côté client ou serveur, et c'est vite une usine à gaz.

2012/4/25 Bruno Marchesson <bruno.ma...@gmail.com>