Petite question d'architecture

Bonjour je souhaiterais avoir votre avis sur la question suivante.
Dans un projet GWT/AppEngine j'ai côté serveur un objet persistant (Objectify) de classe A qui comporte une collection d'objets de classe B. Cet objet doit être rapatrié côté client.

A {
@Id public Long id;
public List<B> bs;
}

B {
@Id public Long id;
...
}

Sachant que le nombre d'objets B va sans cesse augmenter, est-ce que le découpage ci-dessus est correct, ou vaut il mieux faire quelque-chose comme suit :


A {
@Id public Long id;
public List<Long> bIds; // Id de B
}

B {
@Id public Long id;
...
}

Et du coup, les objets B seraient rapatriés à la demande via un service.

Merci d'avance !

Bonjour cereal, voici mon ressenti sur ton problème.

Je pense que les deux solutions dépendent de ta situation.
Maintenant, pour une utilisation standard, je préconiserai la première car tu ramènes tout d'un coup. Il faut voir que dans les deux cas, tu voudras récupérer tes objets B, donc entre tout ramener d'un coup (1ère solution = 1 appel serveur) et les ramener en 2 fois (2ème solution = 2 appels serveur), je pense qu'il est préférable d'utiliser la première technique pour la performance.

Après généralement l'utilisateur n'a pas besoin d'obtenir un nombre de résultats affolants, il cherche juste une partie spécifique des données de la base de données. Du coup, il faut savoir spécifier les objets B retournés en fonction de critères éventuellement fournis par l'utilisateur.

J'espère être clair,
Hope it helps.

Je comprends la problématique du nombre d'appels serveur, mais ce qui me pousse à me poser la question c'est le cas de figure suivant :

Imaginons que l'objet A possède une List<B> de 100000 enregistrements. Si J'ai uniquement besoin des données de A, je suis tout de même obligé de faire transiter les 1000000 enregistrements de B et de les avoir constamment en mémoire vive...
N'est-ce pas un peu plus gourmand que de faire éventuellement un 2ème appel serveur lorsque j'ai besoin de B ?

Et bien soit tu mets en place du lazy loading sur la list d'objets B pour que le chargement n'est lieu que si on accède à cette liste.
Sinon il faut mettre en place de la pagination, potentiellement sur la base de données, ce qui entraine l'implémentation d'une méthode spécifique pour récupérer un liste d'objet B en relation avec A.


Sinon au minimum il faut que l'objet B connaisse son objet A pour manipuler B.

Code:

---

1 2 3 4 5 6 7 8 9 10

A { @Id public Long id; }   B { @Id public Long id; @Id public A a; ... }

---

Citation:

---

Envoyé par cereal

Je comprends la problématique du nombre d'appels serveur, mais ce qui me pousse à me poser la question c'est le cas de figure suivant :

Imaginons que l'objet A possède une List<B> de 100000 enregistrements. Si J'ai uniquement besoin des données de A, je suis tout de même obligé de faire transiter les 1000000 enregistrements de B et de les avoir constamment en mémoire vive...
N'est-ce pas un peu plus gourmand que de faire éventuellement un 2ème appel serveur lorsque j'ai besoin de B ?

---

Si tu sais déterminer dans le code dans quel cas tu ne veux pas ta liste, tu mets ta liste à "null" avant de la traiter.
Si tu ne sais pas identifier ce cas, tu peux en effet utiliser le principe du lazy loading avec Hibernate mais il faut que tu utilises Hibernate dans ton projet.

En gros, avec le lazy loading (lazy=true), si tu veux récupérer ta liste, tu fais un "getListe()" sur ton objet A et tu récupères ta liste par le biais d'une requête Hibernate ; si tu ne veux pas récupérer ta liste, tu ne fais pas de "getListe()" sur ton objet A et aucune requête ne sera envoyée et tu n'auras pas ta liste.

Une autre solution, si les objets B sont "Volumineux". Rapatrié ton objet A avec la liste des Ids. Aller chercher tes objets B 1 part 1 à la demande.

Je pensais effectivement à la dernière solution que tu proposes, mais on est plus vraiment dans l'approche base de données objet. Est-ce qu'une telle méthode est vraiment viable et "professionnelle" ou est-ce un peu "artisanal" ?

A mon sens c'est tout l’intérêt de GWT et de l'approche 2.0 à opposer à l'approche Struts JSP R/O