Discussion :

[gege2061]

Bonjour,

Je suis complément perdu dans la manière de stocker les données pour une application utilisant GWT et hébergée par le service App Engine de google.

Si j'ai bien compris, côté serveur, on peux utiliser JDO pour accéder au datastore.

Mais ensuite comment je récupère mes données côtés client ? A première vue, Google recommande JSON.

Cela signifie que je dois retrouver côté client une copie de la classe qui représente un enregistrement côté serveur en adaptant les types de données (puisque je n'ai plus accès à com.google.appengine.api.*) ? Et gérer la sérialisation/désérialisation en passant par le format JSON pour chaque classe ?

Si vous avez un exemple d'application simple qui fait ça, je suis preneur

[mamelouk]

Salut,

J'ai pas encore eu l'occasion de tester mon application sur app engine, mais en GWT le mécanisme de tranfert de données (entre client et serveur) se fait par des appels RPC. Du pur java, avec un mécanisme de callback pour l'asynchroni..sation. cf le tutorial officiel.

la sérialization/désérialization est gérée par gwt

[gege2061]

J'ai pas encore eu l'occasion de tester mon application sur app engine, mais en GWT le mécanisme de tranfert de données (entre client et serveur) se fait par des appels RPC. Du pur java, avec un mécanisme de callback pour l'asynchroni..sation. cf le tutorial officiel.

la sérialization/désérialization est gérée par gwt

J'ai lu et relus les tuto officiels, j'ai bien compris le système de RPC. Mais comment je fais pour transmettre une classe persistante du serveur au client sachant que l'API utilisée n'ai pas disponible côté client

[mamelouk]

Ah ok je crois comprendre ce que tu veut dire. Tu veut dire que tes objets contiennent des imports JDO (les annotations) que tu peut pas utiliser coté client.

Comme j'utilise hibernate j'ai mappé mes objets avec des fichiers xml pour pouvoir utiliser les meme objets entre couche métier<->hibernate, et entre client <-> couche métier, donc j'ai pas ce problème

Du coup pour passer à AppEngine je veut utiliser les annotations, j'ai décidé d'utiliser des objets pour communiquer entre client<->server et entre server<->jdo. j'ai nommé les premier business object et les second data transfert object et j'utilise un objet replicator pour faire la copie d'un type d'objet vers un autre (je sais pas si les termes sont corrects je suis nouveau en java)

je trouve que c'est plus propre ca ne rend pas les trois couche dépendant du meme modèle objet.

voilà, c'est en cours de codage (sur un projet de bonne taille), je te dirai si y'a des problèmes à implémenter (avec hibernate j'ai eu des problèmes à cause du lazy loading..)

[gege2061]

Ah ok je crois comprendre ce que tu veut dire. Tu veut dire que tes objets contiennent des imports JDO (les annotations) que tu peut pas utiliser coté client.

C'est ça

Du coup pour passer à AppEngine je veut utiliser les annotations, j'ai décidé d'utiliser des objets pour communiquer entre client<->server et entre server<->jdo. j'ai nommé les premier business object et les second data transfert object et j'utilise un objet replicator pour faire la copie d'un type d'objet vers un autre (je sais pas si les termes sont corrects je suis nouveau en java)

je trouve que c'est plus propre ca ne rend pas les trois couche du meme modèle objet.

Effectivement c'est plus simple. Par contre ça me semble quand même relativement lourd à gérer Devoir maintenir trois couches pour un même objet, ça m'étonne que GWT n'est rien de plus souple à proposer.

[mamelouk]

effectivement il faut gérer trois couches, c'est pourquoi ca s'appelle une application trois-tiers

mais seulement deux modèles objets.

mais je disais si tu veut tu peut garder le meme modèle objet partout si l'api de persistence permet de mapper à l'aide de fichiers xml (je suis sur que jdo le peut), en supposant que tu tombe pas sur des problèmes de lazy-loading (hibernate4gwt sert a résoudre ce genre de problèmes)

[ebengtso]

Vous pouvez utiliser DataNucleus aussi pour la couche REST/JSON. voir http://www.datanucleus.org/products/.../rest/api.html

[loudo]

Bonjour,

Si j'ai bien compris vous fonctionnez ainsi.

1) L'objet qui permet la persistance

Code :

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

1
2
3
4
5
6
7
8
9
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class LieuBase {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long key;
 
    @Persistent
    private String nom;
}

2) Le bean qui permet d'échanger entre le client et le serveur

Code :

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

1
2
3
4
5
6
7
 
public class LieuBean implements Serializable {
 
    private Long key;
    private String nom;
 
}

3) J'ai une autre classe qui me permet de gérer les actions sur le serveur et les actions sur le LieuBean et LieuBase

Est ce que vous utilisez cette solution ?

[mamelouk]

Salut,


Oui effectivement, c'est cette solution que j'ai appliquée. C'est un peu lourd parce qu'il faut gérer la copie, mais cela assure que les trois couches sont indépendantes l'une de l'autre.

Un autre effet bénéfique, c'est que s'il y a une information "email de la personne qui a posté ce message" sur le serveur par exemple, elle ne se retrouvera pas dans la page client, sous forme d'objet javascript

J'ai appris ce concept de séparation de modèle en formation de design pattern, donc je suis sur qu'il existe des lib pour faciliter la copie. J'ai repéré BeanReplicator dans BeanLib, mais ca ne fonctionne dans notre cas (les beans doivent etre du meme package)

[loudo]

Merci
Je suis content car j'ai vu vos messages après avoir commencé mon projet et j'avais déjà fait ça. J'ai bien tout séparé pour éviter de stocker des choses sur le client.
J'en profite. Tu as lu la news sur le forum qui indique que le projet gwt-ext a été abandonné par son créateur. Quelle librairie utilises tu ? Est ce que tu as un conseil à me donner ?

Merci.

[benwit]

Effectivement, comme le dit Mamelouk, les adeptes de la séparation en couches préconisent :

• Un "bean métier", (couche bean object).
  Certains en font un vrai objet au sens Java et y mettent des méthodes métiers. D'autres s'en servent uniquement comme objet de données avec mutateurs et accesseurs utilisés par une couche traitement métier (couche bean process).
  
• Son équivalent dans la vue (couche présentation) Ce qui peut avoir un sens pour formater l'affichage/masquer ou non certains champs)
  
• Son équivalent dans le datastore (couche persistance) où il y a le code spécifique au datastore considéré.
  

Cela, c'est la théorie.
Ajouter la complexité (créer des couches) n'a de sens qui si on a plusieurs implémentations possibles.
Dans la pratique, on n'écrit pas des implémentations JDO/JPA/JDBC pour tout un projet.

Ceci dit, je suis quand même pour l'indépendance des couches au cas où.
Ce qui me gène, ce sont ces recopies d'objets un peu lourdes.

J'ai essayé d'être pragmatique et de faire un mixte de tout cela, assurer l'indépendance tout en codant le moins possible des lourdeurs.

J'écris mes Data (bean métier) avec leurs propriétés.
Ces beans sont manipulés par un DataManager (une interface de service) qui peut avoir du coup plusieurs implémentation (JDODataManager, JPADataManager, ...)

Si je peux envoyer ces beans directement à l'ihm, je le fais sans recopie. Pour garder l'indépendance vis à vis de la couche de présentation, mon objet Data implémentera des interfaces ListModel, GridModel, etc ...

Bien entendu, si on ne peut pas (mais il faut que je creuse), je suis obligé de faire une copie des données que l'on souhaite présentée. Passé par du XML ou du JSON permet un découplage plus grand mais on perd l'avantage du RPC.

Au mieux, un objet de données (avec l'utilisation des interfaces pour garder l'indépendance). Au pire, un objet du côté client et un objet du côté serveur.

[benwit]

Si j'ai bien compris, côté serveur, on peux utiliser JDO pour accéder au datastore.

Mais ensuite comment je récupère mes données côtés client ? A première vue, Google recommande JSON.

Cela signifie que je dois retrouver côté client une copie de la classe qui représente un enregistrement côté serveur en adaptant les types de données (puisque je n'ai plus accès à com.google.appengine.api.*) ? Et gérer la sérialisation/désérialisation en passant par le format JSON pour chaque classe ?

Pas si perdu que cela, tu as tout compris !

Si tu utilises JSON, il te faudra gérer la sérialisation/désérialisation. Enfin, je crois qu'il existe des classes GWT pour cela mais je n'ai pas utilisé.

Si tu veux utiliser RPC, il faut que les objets qui transitent soit "GWT compatibles" (voir ce post)