IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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 Vaadin Java Discussion :

Google App Engine et stockage des données


Sujet :

GWT et Vaadin Java

  1. #1
    Rédacteur

    Avatar de gege2061
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    juin 2004
    Messages
    5 840
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : juin 2004
    Messages : 5 840
    Points : 11 463
    Points
    11 463
    Par défaut Google App Engine et stockage des données
    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

  2. #2
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    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

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  3. #3
    Rédacteur

    Avatar de gege2061
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    juin 2004
    Messages
    5 840
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : juin 2004
    Messages : 5 840
    Points : 11 463
    Points
    11 463
    Par défaut
    Citation Envoyé par mamelouk Voir le message
    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

  4. #4
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    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..)

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  5. #5
    Rédacteur

    Avatar de gege2061
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    juin 2004
    Messages
    5 840
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : juin 2004
    Messages : 5 840
    Points : 11 463
    Points
    11 463
    Par défaut
    Citation Envoyé par mamelouk Voir le message
    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

    Citation Envoyé par mamelouk Voir le message
    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.

  6. #6
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    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)

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  7. #7
    Futur Membre du Club
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    5
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : juillet 2005
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    Vous pouvez utiliser DataNucleus aussi pour la couche REST/JSON. voir http://www.datanucleus.org/products/.../rest/api.html

  8. #8
    Membre du Club
    Profil pro
    Chef de projet Informatique
    Inscrit en
    février 2005
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Chef de projet Informatique

    Informations forums :
    Inscription : février 2005
    Messages : 49
    Points : 50
    Points
    50
    Par défaut
    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 ?

  9. #9
    Membre éclairé
    Avatar de mamelouk
    Profil pro
    Inscrit en
    mai 2005
    Messages
    867
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2005
    Messages : 867
    Points : 810
    Points
    810
    Par défaut
    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)

    Débugger du code est deux fois plus dur que d'en écrire.
    Donc, si vous écrivez votre code aussi intelligemment que vous le pouvez, vous n'etes, par définition, pas assez intelligent pour le débugger.

  10. #10
    Membre du Club
    Profil pro
    Chef de projet Informatique
    Inscrit en
    février 2005
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Chef de projet Informatique

    Informations forums :
    Inscription : février 2005
    Messages : 49
    Points : 50
    Points
    50
    Par défaut
    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.

  11. #11
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : septembre 2004
    Messages : 1 676
    Points : 4 135
    Points
    4 135
    Par défaut
    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.

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  12. #12
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : septembre 2004
    Messages : 1 676
    Points : 4 135
    Points
    4 135
    Par défaut
    Citation Envoyé par gege2061 Voir le message
    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)

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

Discussions similaires

  1. Google App Engine Base de données
    Par nico_nico95 dans le forum Général Java
    Réponses: 4
    Dernier message: 20/11/2014, 03h40
  2. Réponses: 2
    Dernier message: 22/01/2012, 16h56
  3. Recupération des données de Google App Engine
    Par Raf_89 dans le forum Android
    Réponses: 0
    Dernier message: 04/04/2011, 11h54
  4. Réponses: 1
    Dernier message: 06/12/2010, 12h02
  5. Réponses: 8
    Dernier message: 09/04/2010, 10h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo