Discussion :

[Alec6]

Bonjour !

Question simple:
- si je vais monEjb.modify(monObjectClient); dans la méthode les attributs de monObjectClient sont modifiés coté server. Est ce que monObjectClient est automatiquement modifié coté client.

ou bien il faut faire un truc du genre monObjectClient=monEjb.modify(monObjectClient).

[Claythest]

C'est quoi "monObjetClient" ? Un entity Bean ???

Il est fortement déconseillé de renvoyer des entity bean au client... Utilise le design pattern Value Object ou Transfer Object :

A transfer object is a serializable class that groups related attributes, forming a composite value. This class is used as the return type of a remote business method. Clients receive instances of this class by calling coarse-grained business methods, and then locally access the fine-grained values within the transfer object. Fetching multiple values in one server roundtrip decreases network traffic and minimizes latency and server resource usage.

http://java.sun.com/blueprints/patte...ferObject.html

[Alec6]

monObjectClient c'est un simple objet qui contient des attributes de type String

[Claythest]

alors oui, ...

il faut faire un truc du genre monObjectClient=monEjb.modify(monObjectClient).

[bubu56]

Il est fortement déconseillé de renvoyer des entity bean au client...

Pourquoi ? En EJB 3 je ne pense pas que cela pose problème. si ?

[Claythest]

Tu peux en effet le renvoyer, c'est possible "techniquement", mais ton entity bean n'a plus rien à voir avec un entity bean... Tu renvoies juste une copie de ton objet, déconnecté de la BD...

[manblaizo]

Tu peux en effet le renvoyer, c'est possible "techniquement", mais ton entity bean n'a plus rien à voir avec un entity bean... Tu renvoies juste une copie de ton objet, déconnecté de la BD...

Oui mais c'est justement une des principales simplifications des EJB3 par rapport aux EJB 2.x CMP, c'est que là tu peux renvoyer tes entity beans au client sous forme d'objets détachés, effectuer les modifications sur la couche présentation, puis par la suite les réattacher dans une nouvelle transaction pour faire la mise à jour de la base de données. Cela permet notamment de simplifier le code en n'étant plus obligé de créer des DTOs et leur factory et autres ... Ces entity beans ne perdent pas leur statut d'entity bean pour autant, à mon avis. Mais bien sûr, un des inconvénients dans ce cas c'est que la couche présentation devient quelque part couplée au model et aux modifications de ce dernier, sans oublier que certaines méthodes d'un entity bean pourraient ne pas être destinées à être appelées par la couche présentation...
En tout cas, c'est une question de goût, je pense, et tant que l'application n'est pas complexe et n'implique pas différentes équipes de développeurs travaillant sur les différentes couches (presentation, business, persistence...) où une définition précise des interfaces entre les couches serait nécessaire, je crois qu'on peut quand même se passer d'une encapsulation totale de la couche business par rapport à la couche présentation.
Voilà, c'est mon avis, mais je pense que le débat a le mérite d'être ouvert.

[Claythest]

Ah ok

Ayant découvert les EJB que depuis les EJB3, et ayant trouvé beaucoup de sites où ils disaient qu'il ne fallaient pas envoyer des entity beans au clients (ils devaient surement parler des EJB2 alors...), j'en avais déduis que c'était le cas depuis toujours et encore aujourd'hui... On en apprends tous les jours

Merci

(et je crois enfin comprendre pourquoi les entity beans doivent implémenter serializable (d'après mon netbeans ) ... )