# Java > Gnral Java > Persistance des donnes >  confusion entre entiy bean , dto et dao

## 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 mappes de la datasource(de mes table par exemple)
la couche dao permet d'interroger la base de donne 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 donnes  ce qui est rellement utile, et d'introduire un dcouplage entre les couches.

----------


## riadhhwajdii

> Le dto est un objet de transfert entre couches. Sa vocation est de restreindre les donnes  ce qui est rellement utile, et d'introduire un dcouplage entre les couches.


merci Tommy mais pourquoi ne pas transporter les beans entits au lieu d'introduire les DTO

----------


## Tommy31

Pour des raisons :

Philosophique, en dcouplant les couches par l'introduction d'interfaces qui portent sur des donnes propres, et non issues du modle sous-jacent.Scuritaire, en circonscrivant le primtre des donnes manipules par la couche suprieure,D'efficacit, si le modle de donnes contient des objets agrgs (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 dcouplant les couches par l'introduction d'interfaces qui portent sur des donnes propres, et non issues du modle sous-jacent.Scuritaire, en circonscrivant le primtre des donnes manipules par la couche suprieure,D'efficacit, si le modle de donnes contient des objets agrgs (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 pige du super dcouplage 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 prsentation: plusieurs coles s'affrontent ici et souvent de faon totalement strile.

Par contre si d'aventure vous avez encore un dao (enore un dbat sympa), il est impratif qu'ils retournent vos objets persistant  la couche de service (c'est elle qui dmarque les transaction et donc souvent la dure 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 bnficiez 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 suprieure  tous les arguments qui sont favorables au maintient des daos...

Hop hop.... bon dbat..

----------


## Tommy31

Les Dao ont une nette tendance  disparatre, tout du moins dans la communaut Java. C'est visible par exemple dans :
Groovy : les objets mtiers portent en eux toutes les mthodes pour assurer leur propre persistance.Spring : l'outil spring gnre des objets mtiers composs d'un coeur mtier, sur lequel viennent se tisser des aspects de persistance. C'est une solution bien lgante et surtout pratique  l'usage.

----------

