IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Contribuez .NET Discussion :

Quelle est la différence entre un DTO et un POCO ?


Sujet :

Contribuez .NET

  1. #21
    Rédacteur/Modérateur
    Avatar de Skalp
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2006
    Messages
    1 694
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 694
    Points : 2 868
    Points
    2 868
    Par défaut
    Citation Envoyé par Alexandre54690 Voir le message
    Justement le but est de ne pas utiliser EF, que je connais mal, mais que beaucoup de développeurs n'aiment pas, sûrement pour de bonnes raisons.
    Quand on "n'aime pas" une technologie, c'est très souvent car on la connait mal.
    Personnellement, j'utilise EF (et EF Core) sur des projets professionnels plus ou moins importants depuis des années maintenant et j'en tire d'inestimables bénéfices (par rapport au temps qu'il m'aurait fallu pour tout écrire de zéro).
    EF est une bibliothèque mature et qui propose des fonctionnalités avancées et performantes. Par contre, je reconnais qu'elle est difficile à maîtriser. Mais au bout du compte, le jeu en vaut la chandelle. Ecrire des requêtes avec LinqToEntities est juste un bonheur de simplicité et de puissance (encore faut-il savoir écrire des requêtes optimisées. Mais ça, c'est comme le SQL).

    Générer soi-même les DTO via des scripts (ou des templates T4) va vous apporter des problèmes sur des cas complexes et/ou tordus.

    D'ailleurs, en ce qui concerne la génération de classes C# à partir d'une base de données, vous pouvez utiliser EF et la méthode "Code First à partir d'une base de données existante", sans pour autant utiliser EF ensuite. Vous utilisez simplement l'Entity Data Model Wizard qui va générer les classes pour vous. Plus d'infos dans cet article : https://docs.microsoft.com/en-us/ef/...sting-database. De cette façon, vous bénéficiez d'un outil puissant et éprouvé par une équipe qui a rencontré et résolu (presque ?) tous les problèmes que vous allez inévitablement rencontrer si vous développez les scripts vous-mêmes.

  2. #22
    Futur Membre du Club
    Homme Profil pro
    Demandeur d'emploi
    Inscrit en
    septembre 2018
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Demandeur d'emploi

    Informations forums :
    Inscription : septembre 2018
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    Chouette article, merci.

    Je sors d'une formation .Net et je me rends compte que le vocabulaire utilisé par les formateurs ne correspond pas.

    On nous a appris que les objets conteneurs de la DAL (simples avec uniquement accesseurs et mutateurs) sont les POCO. Ils sont identiques aux objets DB et contiennent les données issues de la DB mappé en objets C#.

    On a pas évoqué les DTO. Mais ces POCO issus de la DAL sont ensuite mappés dans dans la BAL où toute la logique métier peut s'effectuer. Ici il y a une sorte d'héritage dans la BAL si j'ai bien compris, ce qui évite de devoir mapper.

    En revanche, on a comme c'est expliqué ici vu la persistance séparée dans des Classes "Services" qui s'occupent du CRUD.

    Après cette formation, j'ai entendu le terme DTO. Je pensais qu'un DTO c'était, au niveau de la DAL, un objet qui regroupait le résultat de jointures SQL. Par exemple au lieu de simplement récupérer un étudiant tel quel d'une DB, on récupère aussi les cours qu'il suit pour avoir un objet "enrichi" directement et éviter d'avoir trop de requêtes par la suite.

    J'en profite pour vous poser la question par rapport à ça car ça. Est-ce que c'est une pratique qui se fait de récupérer plus de données de la DB dans les Classes de la DAL? Je crois qu'entity framework ne fait pas ça; il récupère les données d'un objet DB tel quel.

    Merci

  3. #23
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 925
    Points : 4 221
    Points
    4 221
    Par défaut
    Hello.

    Pour la différence entre POCO et DTO. J'avoue que je ne sais pas trop... Je n'ai jamais eu de vraie formation .NET et j'ai tout appris sur le tas via la lecture d'article et l'expérimentation. J'ai personnellement l'impression que c'est la même chose. Juste l'appellation qui change. (Un peu comme voiture et automobile. C'est pourri comme analogie mais c'est tout ce qui me vient ).

    Pour la seconde partie de la question, je dirais que ça dépend du contexte.

    Si tu es par exemple avec une application desktop (WPF par exemple) avec le serveur DB dans le même réseau que toi et que les accès sont rapides, j'aurais tendance à dire de ne récupérer que ce dont tu as besoin à chaque fois. Donc dans le cas de l'étudiant, juste ses propriétés propres. Si tu as besoin de sa liste de cours, une petite requête et en avant (il faut automatiser dans le get de propriété). Dans ce contexte-là, ça devrait être transparent pour l'utilisateur.

    Si tu es dans une application web avec des web service sur Azure par exemple, là par contre, tu vas vouloir faire le moins possible d'aller-retour vers ta DB car c'est vachement lent. Du coup, tu récupères en fait un max d'infos à chaque fois. Entity Framework le fait via la méthode Include des IQueryable. Je sais pas trop comment il se débrouille sous la capot mais en tout cas, ça fonctionne (plus ou moins, j'ai justement un cas bizarre ou une des listes n'est pas chargées tout le temps). Sans clause Include, il ne récupère que l'objet demandé en effet.

    J'espère avoir répondu à ta question. N'hésite pas à attendre d'autres réponses. Comme je l'ai dit, je n'ai jamais eu de vraie formation .NET.
    Kropernic

  4. #24
    Futur Membre du Club
    Homme Profil pro
    Demandeur d'emploi
    Inscrit en
    septembre 2018
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Demandeur d'emploi

    Informations forums :
    Inscription : septembre 2018
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    Hello Kropernic,

    Merci pour ta réponse.

    Il s'agit d'une application web du coup je souhaiterais effectivement minimiser les aller-retour.

    J'ai commencé à récupérer des objets plus complets, c'est à dire issus de jointures. Par contre, ce qui me chiffonne c'est que finalement ces objets ne servent qu'au Get et GetAll.

    Ce que je veux dire c'est que par exemple, je vais devoir avoir un objet C# Etudiant qui correspond à celui en DB pour le Delete, Update, et Insert. Et un autre objet, plus complet pour le Get et GetAll.

    Ca multiplie la création de classes et ça demande plus de taf aussi en terme de mapping. Mais bon si ça permet d'améliore les performances ça vaut la peine.

    C'est d'ailleurs en essayant de trouver un nom pour cet objet complet que j'ai utilisé le terme DTO en me disant qu'il transférait plus de données et pour le différencier de l'objet simple. Donc Etudiant et EtudiantDTO :-)

  5. #25
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 925
    Points : 4 221
    Points
    4 221
    Par défaut
    Je débute dans le domaine du web donc je ne vais pas pouvoir t'aiguiller beaucoup plus. J'ai remarqué ici aussi, sur le projet que j'ai récupéré, qu'il y a des classes qui ont été créées un peu dans tous les sens. Peut-être pour la raison que tu évoques. Je n'ai pas encore analysé cette partie-là. Elle fonctionne donc, je ne touche pas.

    Attention aux noms de tes classes quand même. Tant que tu travailles tout seul, peu importe tant que tu t'y retrouves mais si du monde vient t'aider par après, ce sera plus facile si le nom est cohérent avec ce qu'il se fait ailleurs. Tu pourrais dire EtudiantLight et EtudiantFull par exemple pour éviter d'avoir DTO si tu n'es pas sûr que c'en est un.

    Bref, bon courage pour ton projet
    Kropernic

  6. #26
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    3 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 3 883
    Points : 8 693
    Points
    8 693
    Par défaut
    Citation Envoyé par Kropernic Voir le message
    Pour la différence entre POCO et DTO
    Il me semble qu'il y a une histoire de sérialisation (pour le POCO et que n'a pas le DTO)


    Citation Envoyé par Franz333 Voir le message
    Ce que je veux dire c'est que par exemple, je vais devoir avoir un objet C# Etudiant qui correspond à celui en DB pour le Delete, Update, et Insert. Et un autre objet, plus complet pour le Get et GetAll.

    Ca multiplie la création de classes et ça demande plus de taf aussi en terme de mapping. Mais bon si ça permet d'améliore les performances ça vaut la peine.

    C'est d'ailleurs en essayant de trouver un nom pour cet objet complet que j'ai utilisé le terme DTO en me disant qu'il transférait plus de données et pour le différencier de l'objet simple. Donc Etudiant et EtudiantDTO :-)
    Un DTO est juste un sac à données, donc c'est l'objet qui reçoit, qui va prendre/ valider ce qu'il veut. Et donc, si le DTO a plus de membres, et alors
    C'est justement 1 raison du DTO : on peut rajouter des membres sans que ton application soit impactée (la suppression est plus compliquée )

    Et pour le nom, je préfère l'anglais, et je commence tous mes DTO par "One_" : One_Student, One_Person

  7. #27
    Futur Membre du Club
    Homme Profil pro
    Demandeur d'emploi
    Inscrit en
    septembre 2018
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Demandeur d'emploi

    Informations forums :
    Inscription : septembre 2018
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    Merci

    Tu as raison, c'est justement pour ça que je souhaiterais d'emblée travailler dans les règles. Comme tu disais, qu'on les appelle poco ou dto n'est pas important, mais que l'archi soit correcte et la plus optimale possible est un minimum..

    Merci, courage à toi aussi :-)

  8. #28
    Futur Membre du Club
    Homme Profil pro
    Demandeur d'emploi
    Inscrit en
    septembre 2018
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Demandeur d'emploi

    Informations forums :
    Inscription : septembre 2018
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    Citation Envoyé par foetus Voir le message
    Il me semble qu'il y a une histoire de sérialisation (pour le POCO et que n'a pas le DTO)
    Oui, il y a en effet une histoire de sérialisation.. Du moins je l'ai lu à plusieurs endroits.

    Citation Envoyé par foetus Voir le message
    Un DTO est juste un sac à données, donc c'est l'objet qui reçoit, qui va prendre/ valider ce qu'il veut. Et donc, si le DTO a plus de membres, et alors
    C'est justement 1 raison du DTO : on peut rajouter des membres sans que ton application soit impactée (la suppression est plus compliquée )

    Et pour le nom, je préfère l'anglais, et je commence tous mes DTO par "One_" : One_Student, One_Person
    Si je comprends bien ton utilisation des DTO, elle n'est pas du tout la même que celle décrite dans l'article. Tu parles de validation.. L'article mentionne les DTO comme des objets simples avec mutateurs et accesseurs, sans validation.

    Cela dit, je voyais les DTO comme toi je crois. Plutôt comme des objets auxquels tu donnes les membres que tu veux et qui sont plutôt destinés à fournir les vues (dans le cas du MVC).

    Mon interrogation portait sur comment nommer les objets de la DAL et différencier ceux qui sont identiques à leur homologue en DB de ceux qui rapatrient plus d'information issues de plusieurs tables

  9. #29
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 016
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 016
    Points : 4 102
    Points
    4 102
    Par défaut
    Personnellement j'utilise beaucoup les DTO pour mes api, et au finale j'utilise pas vraiment de POCO dans mes applis, même mes entité ressemble plus à des DTO qu'a des POCO.

  10. #30
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    Les DTO servent a transferer des donnees entre les couches, donc ils ne representent pas forcement les objets tels qu'ils sont. On peut avoir une structure beaucoup plus "plate" (denormalisee) par exemple en renvoyant certaines colonnes provenant de 3 tables differentes, en un seul DTO afin d'eliminer des requetes entre les couches (dans cet example, on fait 1 requete au lieu d'en faire 3). En regle generale, les DTO n'ont pas de comportement propre (donc juste des proprietes, aucune methode). Un DTO ne sert donc qu'a transferer un etat, et juste les donnees necessaires.

    Les POCO peuvent avoir un comportement (donc des proprietes + des methodes). Ils sont plus proches de la structure reelle des objets et ils ne doivent pas servir a transferer des donnees entre les couches. Un POCO est donc plus un concept de programmation associe a de la programmation orientee objets (OOP).

    Dans des projets ayant une certaine complexite (en general des applis distribuees), il n'est pas rare d'avoir une couche d'objets POCO et une couche DTO, les POCO etant convertis en DTO lorsqu'on a besoin d'envoyer des donnees.

    J'ai lu plus haut des remarques au sujet de la serialization. On peut tout a fait serialiser un POCO mais ca n'est pas l'objectif : on peut serialiser un etat, mais pas un comportement.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  11. #31
    Futur Membre du Club
    Homme Profil pro
    Demandeur d'emploi
    Inscrit en
    septembre 2018
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Demandeur d'emploi

    Informations forums :
    Inscription : septembre 2018
    Messages : 5
    Points : 6
    Points
    6
    Par défaut
    Citation Envoyé par DotNetMatt Voir le message
    Les DTO servent a transferer des donnees entre les couches, donc ils ne representent pas forcement les objets tels qu'ils sont.

    Les POCO ... et ils ne doivent pas servir a transferer des donnees entre les couches.
    J'ai du mal avec cette question du transfert de données. Une classe, DTO ou POCO, va d'office contenir des valeurs et les transmettre d'une couche à une autre. Non?

    Mais donc pour revenir au DTO, dès l'instant où une classe dans ma DAL va contenir un résultat de plusieurs jointures, je devrais nommer cette classe DTO?

Discussions similaires

  1. Réponses: 12
    Dernier message: 01/06/2010, 16h57
  2. Réponses: 5
    Dernier message: 03/05/2005, 18h22
  3. Réponses: 11
    Dernier message: 31/01/2005, 17h48
  4. Quelle est la différence entre le float et le real ?
    Par Manson dans le forum Débuter
    Réponses: 3
    Dernier message: 10/08/2004, 17h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo