<!-- Slide number: 1 -->
DTO
&
DAO
Présenter par : Yassine Lahbib
Aymen Zairi
1
<!-- Slide number: 2 -->
DTO Data Transfer Object :
2
Dans une architecture multi-couches sans état, il est relativement fréquent de s'échanger des graphes d'objets en paramètre de méthode. Aujourd'hui le pattern DTO (Data Transfert Object) est la technique la plus utilisée pour assurer le découplage entre la couche de présentation et les objets métier stockés sur le serveur.
<!-- Slide number: 3 -->
Utilité des DTOs :
3
Les DAOs sont situés dans une couche proche de la base de données
Publicité
Les DTOs peuvent être utilisés pour transporter les données entre les différentes couches distantes
Le code utilisateur des DAOs est souvent situé sur une autre couche distante
<!-- Slide number: 4 -->
Le problème à résoudre :
4
Un client souhaite récupérer des données en interrogeant des objets distants non facilement transportables sur le réseau
Exemple : récupérer les nom, prénom, salaire et lieu de travail d’un employé
S’il utilise les accesseurs des classes des objets (getNom, getPrenom, getSalaire, getLieu), plusieurs appels distants sont nécessaires
<!-- Slide number: 5 -->
La Solution DTO :
5
Le client demande un objet qui contient toutes les valeurs dont il a besoin
Cet objet, un Data Transfert Object (DTO), est construit sur le site distant et passé en une seule fois au client
Un DTO contient l’état d’un ou de plusieurs objets métier, mais pas leur comportement
<!-- Slide number: 6 -->
Publicité
Exemples d’utilisation des DTO :
6
Transporter les données d’un objet distant pas transportable sur le réseau (pas sérialisable)
Transporter plusieurs objets distants en un seul appel distant ; par exemple une facture avec toutes les lignes de facture et les informations sur les produits
<!-- Slide number: 7 -->
DAO Data A Object :
7
Le pattern DAO (Data Access Object) permet de faire le lien entre la couche métier et la couche persistante, ceci afin de centraliser les mécanismes de mapping entre notre système de stockage et nos objets Java. Il permet aussi de prévenir un changement éventuel de système de stockage de données (de PostgreSQL vers Oracle par exemple).
<!-- Slide number: 8 -->
Les caractéristiques générales de DAO sont les suivantes:
8
codage difficile .
souplesse, avec possibilité d'accéder à de nombreuses sources de données différentes .
performances modérées .
prise en charge des curseurs complexes .
Publicité
<!-- Slide number: 9 -->
Le Problème à résoudre :
9
Le code pour la persistance varie beaucoup
avec le type de stockage (BD relationnelles, BD objet, fichiers simples, etc.)
avec les implémentations des fournisseurs de SGBD
Si les ordres de persistance sont imbriqués avec le code « métier », il est difficile de changer de source de données
<!-- Slide number: 10 -->
La Solution :
10
Encapsuler le code lié à la persistance des données dans des objets DAO dont l’interface est indépendante du support de la persistance
Le reste de l’application utilise les DAOs pour gérer la persistance, en utilisant des interfaces abstraites
<!-- Slide number: 11 -->
Utilité des DAOs :
11
Publicité
Plus facile de modifier le code qui gère la persistance (changement de SGBD ou même de modèle de données)
Factorise le code d’accès à la base de données
Plus facile pour le spécialiste des BD d’optimiser les accès (ils n’ont pas à parcourir toute l’application pour examiner les ordres SQL)
Sans doute le modèle de conception le plus utilisé dans le monde de la persistance
<!-- Slide number: 12 -->
CRUD :
12
Ces 4 opérations de base sont implémentées dans un DAO.
Create pour créer une nouvelle entité dans la base.
Retrieve pour retrouver une ou plusieurs entités de la base .
Update pour modifier une entités de la base.
Delete pour supprimer une entité de la base .