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?