SQL)

Sans doute le mod le de conception le plus

utilis dans le monde de la persistance

<!-- Slide number: 5 -->

Le principe de DAO

Le principe du pattern DAO est de s parer la couche mod le d'une application en deux sous-couches distinctes :

une couche g rant les traitements m tier appliqu s aux donn es, souvent nomm e couche service ou m tier. Typiquement, tout le travail de validation r alis dans nos objets InscriptionForm et ConnexionForm en fait partie ;

une couche g rant le stockage des donn es, logiquement nomm e couche de donn es. Il s'agit l des op rations classiques de stockage : la cr ation, la lecture, la modification et la suppression. Ces quatre t ches basiques sont souvent raccourcies l'anglaise en CRUD.

<!-- Slide number: 6 -->

#

Pour r aliser efficacement une telle op ration, il est n cessaire d'encapsuler les exceptions sp cifiques au mode de stockage dans des exceptions personnalis es et propres la couche DAO. Dans notre cas par exemple, nous allons devoir faire en sorte que les exceptions propres SQL ou JDBC ne soient pas vues comme telles par nos objets m tier, mais uniquement comme des exceptions manant de la bo te noire qu'est notre DAO.

De m me, il va falloir masquer le code responsable du stockage au code ext rieur , et l'exposer uniquement via des interfaces. Dans notre cas, il s'agira donc de faire en sorte que le code bas sur JDBC soit bien l'abri dans des impl mentations de DAO, et que nos objets m tier n'aient connaissance que des interfaces qui les d crivent.

<!-- Slide number: 7 -->

#

! (r2136700.jpg)

<!-- Slide number: 8 -->

#

La couche mod le est constitu e de la couche m tier (en rouge) et de la couche donn es (en vert). La couche m tier n'a connaissance que des interfaces d crivant les objets de la couche donn es. Ainsi, peu importe le syst me de stockage final utilis , du point de vue du code m tier les m thodes appeler ne changent pas, elles seront toujours celles d crites dans l'interface. C'est uniquement l'impl mentation qui sera sp cifique au mode de stockage.

<!-- Slide number: 9 -->

#

la couche DAO ne va pas seulement contenir les interfaces et impl mentations des m thodes CRUD. Elle va galement renfermer quelques classes d di es l'isolement des concepts li s au mode de stockage, comme les exceptions dont nous avons d j bri vement parl , mais galement le chargement du driver et l'obtention d'une connexion. Pour ce faire, nous allons cr er une Factory (une fabrique) qui sera unique dans l'application, ne sera instanci e que si les informations de configuration sont correctes et aura pour r le de fournir les impl mentations des diff rents DAO.

<!-- Slide number: 10 -->

#

En ce qui concerne la relation entre la couche m tier et le DAO, c'est tr s simple : les objets m tier appellent les m thodes CRUD, qui ont pour r le de communiquer avec le syst me de stockage et de peupler les beans repr sentant les donn es.

<!-- Slide number: 11 -->

Avantages et inconv nients

L'utilisation de DAO permet de s'abstraire de la fa on dont les donn es sont stock es au niveau des objets m tier. Ainsi, le changement du mode de stockage ne remet pas en cause le reste de l'application. En effet, seules ces classes dites "techniques" seront modifier (et donc re-tester). Cette souplesse implique cependant un co t additionnel, d une plus grande complexit de mise en Suvre.

<!-- Slide number: 12 -->

DTO

<!-- Slide number: 13 -->

D finition de DTO

Un objet de transfert de donn es (data transfer object ou DTO en anglais) est un patron de conception utilis dans les architectures logicielles objet.

Son but est de simplifier les transferts de donn es entre les sous-syst mes d'une application logicielle. Les objets de transfert de donn es sont souvent utilis s en conjonction des objets d'acc s aux donn es.

Le DTO se distingue du DAO (objet d'acc s aux donn es) car il ne permet que de modifier ou d'acc der ses donn es (avec des mutateurs et accesseurs).

<!-- Slide number: 14 -->

#

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.

Les DTO sont des structures de donn es qui v hiculent l' tat (les propri t s de cet objet un instant T) des objets serveur sur le client et permettent galement de remonter des informations persister.

<!-- Slide number: 15 -->

#

Un DTO nest rien de plus qu'une classe exposant des propri t s, mais pas de m thodes. Du point de vue design pur, le pattern DTO est une solution quasi parfaite car il permet disoler le mod le du domaine de la pr sentation, permettant la fois un couplage l che et un transfert de donn es optimis .

<!-- Slide number: 16 -->

Avantages des DTO

Am lioration des performances. En transmettant plus de donn es dans un seul appel distant, l'application peut r duire le nombre d'appels distants. Les appels distants ralentissent consid rablement les applications. La r duction du nombre d'appels est l'un des meilleurs moyens d'am liorer les performances.

Transparence des m canismes internes. Le fait d' mettre et de recevoir davantage de donn es dans un seul appel masque plus efficacement les m canismes internes d'une application distante derri re une interface granularit grossi re.

D couverte d'objets m tier. Dans certains cas, le fait de d finir un DTO aide d couvrir des objets m tier pertinents. Lorsque l'on cr e des classes personnalis es servant de DTO, on remarque souvent des regroupements d' l ments qui sont pr sent s un utilisateur ou un autre syst me en tant qu'ensemble coh rent d'informations.

Aptitude au test. L'encapsulation de tous les param tres dans un objet s rialisable peut favoriser l'aptitude au test. Par exemple, on peut lire les DTO partir d'un fichier XML et appeler des fonctions distantes pour le tester.

<!-- Slide number: 17 -->

Inconv nients des DTO

Risque de multiplication du nombre de classes. Si vous choisissez d'utiliser des DTO fortement typ s, vous devrez peut- tre cr er un (ou deux, en tenant compte de la valeur de retour) DTO pour chaque m thode distante. M me dans une interface granularit grossi re, cela peut induire un grand nombre de classes. Il peut devenir difficile d'en coder et g rer une telle quantit . La g n ration de code automatique peut palier en partie ce probl me.

Calculs suppl mentaires. Le fait de convertir un format de donn es sur le serveur en flux d'octets transportable sur le r seau, puis nouveau en format objet dans l'application cliente, peut induire une surcharge assez importante. En g n ral, on agr ge des donn es provenant de sources diverses dans un seul DTO sur le serveur. Pour am liorer l'efficacit des appels distants sur le r seau, il faut faire quelques calculs suppl mentaires d'un c t ou de l'autre pour agr ger et s rialiser les informations via des outils comme Dozer.

<!-- Slide number: 18 -->

#

Codage suppl mentaire. Le DTO demande d'instancier un nouvel objet et d'appeler des m thodes d'obtention et de r glage pour chaque param tre. L' criture de ce code peut tre fastidieuse, m me si des outils comme Dozer simplifient cette t che.

En r sum , le principal argument contre l'utilisation de DTO est le travail suppl mentaire n cessaire pour crire et de g rer le nombre de classes DTO r sultantes. Dans des projets volumineux, le d couplage de la pr sentation et de la couche de service n cessitera limpl mentation de centaines de nouvelles classes.

<!-- Slide number: 19 -->

faut-il utiliser les DTO ?

Les DTO sont l'objet d'un choix de conception important qui affecte l'impl mentation de toute communication entre la pr sentation et le serveur principal du syst me.Lutilisation des DTO n'est pas un point facile g n raliser. Pour tre efficace, la d cision finale doit toujours effectu e en examinant les d tails du projet.

<!-- Slide number: 20 -->

Utilisation des DTO

Affichage distant du mod le du domaine Plusieurs contextes applicatifs diff rents Performance (liste daffichage) Maitrise de limpl mentation de la pr sentation et des services dilu e.

<!-- Slide number: 21 -->

#

! (Espacer serv ducontenu3.jpg)