Discussion :

[Cisman]

Bonjour, je suis sur un projet java, et je dois faire des requêtes CRUD sur une base de données, mes requêtes séparées fonctionnent. Je compte le faire via une facade et utiliser un facroty pour mon CRUD.
Ce que j'ai du mal à comprendre, c'est la différence entre DAO et DTO...

Si quelqu'un d'aguérri pouvait m'expliquer.

[wax78]

DTO qui veut dire "Data Transfer Object" sont des objets qui vont contenir les données en tant que tel (exemple le DTO Client qui va contenir des propriété genre Nom, Prenom, Adresse, etc). Ils ne contiennent généralement pas de "logique métier"

DAO qui veut dire "Data Access Object" est ce qui va contenir les méthodes permettant de récupérer, insérer, mettre a jour, effacer tes DTOs dans le système de stockage (BD, Fichiers, etc.)

[OButterlin]

On commence par le plus simple, le DTO (Data Transfer Object) :
C'est un objet qui défini la structure des informations à échanger, généralement, Serializable.
En gros, c'est l'objet qui circule entre les différentes couches de ton application.

Le DAO (Data Access Object) :
C'est l'objet qui contient les méthodes d'accès aux données de la base de données.
On peut utiliser JDBC ou JPA ou Hibernate (ou autre ORM) pour le faire mais c'est bien cette classe qui s'en occupe.
On y retrouve généralement les méthodes de base :
- create(...) pour créer un enregistrement en DB
- update(...) pour modifier un enregistrement existant en DB
- delete(...) pour supprimer l'enregistrement en DB
- findAll(...) pour récupérer la liste des enregistrements correspondant aux critères
- get(...) (ou find(...)) pour récupérer l'enregistrement sur sa clé primaire

Les paramètres de ces méthodes dépendent un peu de la technologie, avec JPA on serait tenté d'avoir un entity en paramètre mais on pourrait systématiquement utiliser le DTO :
- create(dto)
- upate(dto)
- delete(dto)
- List<dto> findAll(... liste des filtres de requête)

Bref, le DAO est un peu plus compliqué que le DTO

EDIT : damned, grillé

[wax78]

EDIT : damned, grillé

Peut être mais c'est moins laconique que mon texte

[foetus]

DTO qui veut dire "Data Transfer Object" sont des objets qui vont contenir les données en tant que tel (exemple le DTO Client qui va contenir des propriété genre Nom, Prenom, Adresse, etc). Ils ne contiennent généralement pas de logique métier

Effectivement, ce n'est pas qu'un gros sac à données (comme une structure en langage C) : il y a toutes les méthodes pour configurer, remettre à zéro, nettoyer ces données.

[Cisman]

On commence par le plus simple, le DTO (Data Transfer Object) :
C'est un objet qui défini la structure des informations à échanger, généralement, Serializable.
En gros, c'est l'objet qui circule entre les différentes couches de ton application.

Le DAO (Data Access Object) :
C'est l'objet qui contient les méthodes d'accès aux données de la base de données.
On peut utiliser JDBC ou JPA ou Hibernate (ou autre ORM) pour le faire mais c'est bien cette classe qui s'en occupe.
On y retrouve généralement les méthodes de base :
- create(...) pour créer un enregistrement en DB
- update(...) pour modifier un enregistrement existant en DB
- delete(...) pour supprimer l'enregistrement en DB
- findAll(...) pour récupérer la liste des enregistrements correspondant aux critères
- get(...) (ou find(...)) pour récupérer l'enregistrement sur sa clé primaire

Les paramètres de ces méthodes dépendent un peu de la technologie, avec JPA on serait tenté d'avoir un entity en paramètre mais on pourrait systématiquement utiliser le DTO :
- create(dto)
- upate(dto)
- delete(dto)
- List<dto> findAll(... liste des filtres de requête)

Bref, le DAO est un peu plus compliqué que le DTO

EDIT : damned, grillé

Merci pour ton explication limpide

[stefv]

On commence par le plus simple, le DTO (Data Transfer Object) :
C'est un objet qui défini la structure des informations à échanger, généralement, Serializable.
En gros, c'est l'objet qui circule entre les différentes couches de ton application.

Le DTO est plus spécifique d'un objet de transport entre les couches. Il s'agit d'un objet qui transite entre les couches réseau. Son but est de regrouper toutes les informations nécessaires à un traitement distant. On peut imaginer par exemple un front devant appeler un back et pour éviter de faire de multiples appels, on met toutes les données nécessaires dans ce DTO.

Je précise car j'ai constaté plusieurs fois des projets où les développeurs utilisaient le terme de DTO pour des objets internes au back, et c'est une erreur qui apporte de la confusion, de la complexité à l'architecture et au code, surtout lorsque l'on est nouveau développeur.