Discussion :

[vseb99]

Petite question, j'ai une couche métier contenant des objets métier faisant le lien avec la base de données, sans passé par des entity bean.
Je prévois de développer une partie serveur pour manipuler ces POJOS et développer la logique métier.
Et enfin j'ai un client RCP/SWT distant sur le client.

Ma question est de savoir comment je récupère mes POJOS côté client pour afficher dans l'interface? Est ce que je dois passer par un objet intermédiaire?
Est ce que je doit avoir le jar de la couche métier côté client?

merci pour vos réponses

[vseb99]

Pour compléter, en fait c'est une question d'architecture applicative. Comment éviter les forts couplages entre les couches logicielles qu'implique l'utilisation des POJOS côté client.

C'est plus clair ou pas ?

[fr1man]

Côté client, tu auras besoin de tes POJOS et des interfaces de tes EJBs.

[vseb99]

Ce qui m'embête c'est que ce ne sont pas vraiment des POJOS au sens JPA, ces classes embarquent des méthodes qui appellent des procédures stockées métier. Et elles sont construites via JDBC avec des annotations développées par nous même.
De plus elles font parties d'un modèle objet décrivant le métier proprement dit, et si quelque chose change dans ce modèle il faudra que je le répercute côté client d'où une certaines lourdeur.

Finalement est ce que l'utilisation d'interface dans ma couche métier et d'objet DTO pour gérer la conversation entre couche ne serait pas la meilleure solution. (design pattern de type MVC)


Même si ce type d'architecture semble un peu désuète avec les EJB3.

[fr1man]

Tu parlais de POJOS, je pensais donc à de simple objets java, en gros des propriétés et des getter/setter.
Effectivement si tu as des appels vers la base de données, tu ne dois pas renvoyer ces objets à ton client.
Tu dois renvoyer soit des DTO, soit de vrais POJOS qui représentent tes données et qui ne font que ça.

[OButterlin]

Il y a tout de même un problème d'architecture là.
Tu mixes finalement un DAO avec un "entity" (au sens EJB3 du terme)

La solution DTO me paraît bonne, surtout si tu veux une plus grande indépendance entre ton client et le modèle métier.