DTO & POCO : Quid de l'héritage ?

**Kikuts** · 03/07/2013, 09h35

Ca dépend de la structure de ton projet. Si tu n'as pas d'autres projet Model que ton projet DTO alors 2 possibilités : soit tu vas avoir besoin de cette classe dans un autre projet (windows phone par ex) dans ce cas, tu pourrais créer un dossier wrapper dans tes DTO, soit (ce que je fais) tu rajoutes un dossier wrapper ou model dans ton projet contenant l'UI.

De plus en mettant cette classe côté projet client, tu peupleras ta liste de données côté client aussi

du coup ça allège un micro poil ton serveur

Après, si ton projet était en silverlight, wpf ou windows phone, tu pourrais créer un converter qui te permettrait de ne pas afficher le contenue de la propriété Nombre (pour mue et portée par ex) qui affiche vide si nombre négatif.

**DotNetMatt** · 03/07/2013, 10h25

Ce n'est pas un objet DTO, même si ça y ressemble.

Donc il faudrait (à mon avis) rajouter un dossier dans le projet UI avec ces objets, ou alors créer un projet à part genre "Projet.UI.BindingWrappers" si tu peux avoir besoin de réutiliser ce code dans plusieurs projets UI.

**Kropernic** · 03/07/2013, 10h50

Cela confirme bien ce que je pensais.

+1 avec l'avis de DotNetMatt

@Kikuts : Merci mais t'es trop technique pour moi ^^. Ici, je suis juste dans un petit service informatique d'un magasin. Alors les project models, silverlight et autre WPF, on ne sait pas ce que c'est XD

**rv26t** · 03/07/2013, 14h21

Envoyé par Kropernic

Un dernier détail... Dans quelle couche placeriez-vous ce wrapper ?

Instinctivement, je l'ai placé dans la couche DTO mais je me demande s'il ne serait pas mieux dans la couche GUI.

En effet, les DTO vivent très bien sans. Il n'y a que la partie graphique qui en a besoin pour une raison technique dont les autres couches se moquent totalement.

Qu'en pensez-vous ?

Le besoin représente une nécessité métier : présenter des données issues de tables ayant une structure différentes. Avec la solution : Wrapper (que l'on pourrait définir comme : constructeur de liste particulière pour l'affichage).
Donc pourquoi ne pas le placer dans la couche métier BLL ? (c'est juste mon avis) Si ce wrapper peut servir a plusieurs applis, soit comme il a été dit le placer dans un projet, ou dans une bibliothéque (une référence dans les projets et hop)

L'UI se bornant à présenter les données (pas à les préparer sous forme de liste)

Après l'idée de DotNetMatt avec " "Projet.UI.BindingWrappers" " est intéressante puisque qu'elle est dédié à des fonctionalités particulières.

**Kikuts** · 03/07/2013, 14h36

Ce n'est pas un objet DTO, même si ça y ressemble.

Alors là, on peut débattre longtemps

Si on en reste à la définition pure et dure, DTO = Data Transfert Object. Donc si on construit (alimente la liste) ce wrapper côté serveur, on pourrait considérer cet objet comme un DTO n'est-ce pas ? Ou alors un ModelDTO ?

Pour détailler plus : s'il garde son wrapper côté client, il faudra qu'il lance 2 appels webservices sans wrapper côté serveur. Pour récupérer la liste de Chien et celle de Serpent (même si j'ai un doute car je ne sais plus si en retournant une liste d'animaux, on pourra avoir les Chien et Serpent tout en ayant leurs propriétés spécifiques, auquel cas, il n'y aura qu'un appel)

Or s'il construit sa liste d'objets wrapper côté serveur, un seul appel et aucun traitement supplémentaire côté client, ni dans aucune autre UI qui appelerait cette fonction ! (que ce soit un AnimalWrapperDTO ou un AnimalWrapperBLL comme l'a dit Hervé)

Donc moins de maintenance si on chipote

Maintenant j'attend confirmation des experts

Mais il est vrai que le mieux à faire est de créer un projet pour stocker les wrapper pour les réutiliser dans d'autres (futures) projets.

Invité · 03/07/2013, 14h54

Si on se limite à la définition simple et basique de ce qu'est le pattern DTO comme le dit le grand Martin Fowler dans un extrait ici et dans son livre Entreprise Patterns of Enterprise Application Architecture je me dis que l'application qui mettra en place tout ce qui est dit ici après 84 réponses tournera à une overdose de patterns, de couches ou de tout ce que je n'ai pas pensé mais qui est lié à vouloir pousser à l'infini le découpage.

N'oubliez pas le KISS : Keep it Simple & Straightforward « Laisse-le simple et direct ». That's my 2 cents

**DotNetMatt** · 03/07/2013, 14h56

Envoyé par Kikuts

Si on en reste à la définition pure et dure, DTO = Data Transfert Object. Donc si on construit (alimente la liste) ce wrapper côté serveur, on pourrait considérer cet objet comme un DTO n'est-ce pas ? Ou alors un ModelDTO ?

Ben comme je l'ai dit, ça y ressemble mais ça n'est pas un DTO. Un DTO est un objet "libre", que l'on balade entre les couches afin de transporter des données. Le wrapper est créé par la couche BLL, à partir d'un ou de plusieurs objets DTO. Il sera ensuite consommé par l'UI lors du Binding. Son transit se limite à un trajet entre BLL et UI uniquement.

Donc pour répondre à ta question, je dirais que non, ou alors on ne fait pas la même interprétation du Wrapper.

Envoyé par Kikuts

Pour détailler plus : s'il garde son wrapper côté client, il faudra qu'il lance 2 appels webservices sans wrapper côté serveur. Pour récupérer la liste de Chien et celle de Serpent (même si j'ai un doute car je ne sais plus si en retournant une liste d'animaux, on pourra avoir les Chien et Serpent tout en ayant leurs propriétés spécifiques, auquel cas, il n'y aura qu'un appel)

Or s'il construit sa liste d'objets wrapper côté serveur, un seul appel et aucun traitement supplémentaire côté client, ni dans aucune autre UI qui appelerait cette fonction ! (que ce soit un AnimalWrapperDTO ou un AnimalWrapperBLL comme l'a dit Hervé)

Le coût de construction de l'objet Wrapper est négligeable, à moins d'avoir de gros objets à binder... Il s'agit juste de transférer les infos d'un ou plusieurs DTO dans le Wrapper, afin de pouvoir binder proprement derrière.

Envoyé par Kikuts

Mais il est vrai que le mieux à faire est de créer un projet pour stocker les wrapper pour les réutiliser dans d'autres (futures) projets.

Nous sommes d'accord sur ce point

**Kropernic** · 03/07/2013, 14h57

Je n'ai qu'un appel coté client pour récupérer ma liste d'animaux. C'est justement l'intérêt de l'héritage.

Quant à la place du wrapper. Au final, tant que ça fonctionne, l'utilisateur il s'en tape ^^.

Mais d'un point de vue technique, je pense que Hervé à probablement raison. En "l'injectant" dans la couche BLL, on pourrait créer une fonction dans AnimalCDD qui renverrait une liste du wrapper.

EDIT : Grillé par hs et matt le temps de filer une liste de user à un auditeur ^^

**rv26t** · 03/07/2013, 15h33

Envoyé par Kropernic

Je n'ai qu'un appel coté client pour récupérer ma liste d'animaux. C'est justement l'intérêt de l'héritage.
Quant à la place du wrapper .... d'un point de vue technique, ... En "l'injectant" dans la couche BLL, on pourrait créer une fonction dans AnimalCDD qui renverrait une liste du wrapper.

Cela me semble une bonne idée de le placer dans la BLL, vu que l'on peut considérer le Wrapper comme un assembleur d'info, et qu'il agit en tant que fonctionnalité métier.

La discution devient un roman, mais elle a permit des avancées. (sans morceler l'appli inutilement)
@ h2s84 : j'ai jeté un oeil rapide sur une partie du projet (.rar) de Kropernic. Le travail est propre, bien structuré.

**Kropernic** · 03/07/2013, 16h24

Envoyé par rv26t

@ h2s84 : j'ai jeté un oeil rapide sur une partie du projet (.rar) de Kropernic. Le travail est propre, bien structuré.

Merci

.
Mais de quel .rar tu parles ? ^^ Les 3 que j'avais mis en pièce jointe pour kikuts ?

Sinon pour donner une idée, voilà la tronche de la solution dans l'explorateur de solution (voir pièce jointe). Je n'ai montré que la couche GUI et DTO car le reste, ça ne rentre pas ^^. DAL et BLL ont les mêmes fichier que DTO mis à part des classes de bases propres à chaque couche.

**Kikuts** · 04/07/2013, 15h53

Je cède alors

ce n'est pas un DTO

Oui la discussion à pas mal trainée haha

Mais très instructive !

**Sankasssss** · 04/07/2013, 17h02

Envoyé par Kikuts

Oui la discussion à pas mal trainée haha

Mais très instructive !

Comme toujours avec Kropernic

C'était effectivement très instructif, merci à tous les intervenants !!!

**chaparo** · 05/07/2013, 06h47

Histoire de parler un exemple concret, voici un "bête" exemple de DTO (et des parsers qui vont avec en référence à la série d'articles de R. Lacovara)

Merci Kropernic pour ce lien.