Discussion :

[Skalp]

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.

[Franz333]

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

[Kropernic]

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.

[Franz333]

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 :-)

[Kropernic]

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

[foetus]

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)

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

[Franz333]

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 :-)

[Franz333]

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.

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

[youtpout978]

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.

[DotNetMatt]

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.

[Franz333]

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?