Discussion :

[Onarap]

Lorsque le mapping est "bag" ou "set", Hibernate instancie des PersistentBag ou PersistentSet. Y a-t-il un moyen de le forcer à instancier des implémentations de List ou Set issues du package java.util ? Même avec lazy="false" et en initialisant le membre p.ex. "private List<Item> items = new ArrayList<Item>();", je ne parviens pas à le faire.
Du coup, on doit distribuer hibernate.jar du côté client, ce qui n'est pas vraiment idéal...

[the-gtm]

Tu peux remplacer ces objets lors de la serialisation, par exemple en implémentant Externalizable. Au lieu de faire

Code :

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

out.writeObject(set);

tu fais

Code :

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

out.writeObject(new HashSet(set));

[Onarap]

Donc je devrais implémenter la sérialisation de tous les DTOs

Admettons...

Que se passera-t-il lorsque le client renvoie les données au serveur?

Je me pose la question parce que j'ai remarqué la chose suivante: il est important pour hibernate de garder la référence sur les listes.
(d'ailleurs il a sa propre implémentation de List : PersistentBag)

P.ex. si j'ai une classe Category qui contient une liste d'Items:

Code :

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

1
2
category.getItems().clear();
categroy.getItems().add(new Item());

fonctionne comme on s'y attend c'est à dire que les items existants sont effacés, alors que

Code :

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

1
2
category.setItems(new ArrayList<Item>());
categroy.getItems().add(new Item());

fonctionne aussi mais le nouvel item est en fait ajouté! Au prochain load la ToDo aura un item de plus, cce qui n'est pas intuitif comme comportement.

Donc au final si j'utilise ta méthode je risque bien d'influer de manière non désirée sur le comportement de hibernate.