Discussion :

[riadhhwajdii]

salut,
j'ai une ambiguité à comprendre les differnces entre les 3 termes:entiy bean, dto et dao
ce que je connait est que :

• les entiy bean presentent les objets mappées de la datasource(de mes table par exemple)

• la couche dao permet d'interroger la base de donnée et centraliser les requtes

est ce que je suis correct et q'elle est alors l'interet de la couche dto

[Tommy31]

Le dto est un objet de transfert entre couches. Sa vocation est de restreindre les données à ce qui est réellement utile, et d'introduire un découplage entre les couches.

[riadhhwajdii]

Le dto est un objet de transfert entre couches. Sa vocation est de restreindre les données à ce qui est réellement utile, et d'introduire un découplage entre les couches.

merci Tommy mais pourquoi ne pas transporter les beans entités au lieu d'introduire les DTO

[Tommy31]

Pour des raisons :

• Philosophique, en découplant les couches par l'introduction d'interfaces qui portent sur des données propres, et non issues du modèle sous-jacent.
• Sécuritaire, en circonscrivant le périmètre des données manipulées par la couche supérieure,
• D'efficacité, si le modèle de données contient des objets agrégés (ce qui est souvent le cas), il est plus performant de travailler sur une vue que sur la structure originelle.

[riadhhwajdii]

Pour des raisons :

• Philosophique, en découplant les couches par l'introduction d'interfaces qui portent sur des données propres, et non issues du modèle sous-jacent.
• Sécuritaire, en circonscrivant le périmètre des données manipulées par la couche supérieure,
• D'efficacité, si le modèle de données contient des objets agrégés (ce qui est souvent le cas), il est plus performant de travailler sur une vue que sur la structure originelle.

merci Tommy ca devient un peu plus claire, une autre chose, est ce qu'il y a un pattern à appliquer pour la couche dto

[denisjava]

Attention au piège du super découplage qui donne lieu à des erreurs de design monumentales (impliquant en plus des pb de performances catastrophiques).

Je n'évoque pas l'utilisation des objets persistants (ceux que tu appelles des entity beans) par la couche de présentation: plusieurs écoles s'affrontent ici et souvent de façon totalement stérile.

Par contre si d'aventure vous avez encore un dao (enore un débat sympa), il est impératif qu'ils retournent vos objets persistant à la couche de service (c'est elle qui démarque les transaction et donc souvent la durée de vie de votre entitymanager en jpa ou de votre session en hibernate). si vos daoretourne des dto qui ne sont pas vos objets persistent, alors vous ne bénéficiez plus de dirty checking (qui est quand meme un des points essentiels des ORM). vous devez alors synchroniser manuellement vos objets (via session.update par exemple ou em.merge)

Moi perso, je suis favorable à la disparition des dao dans 90% des cas. La plus value en terme de simplicité est largement supérieure à tous les arguments qui sont favorables au maintient des daos...

Hop hop.... bon débat..