Discussion :

[DotNetMatt]

@meziantou : on dirait que tu as fusionné ta DAL et ta BLL (corrige-moi si je me trompe). Attention, ADO.NET n'est pas une couche en soit, c'est juste une API

Je prends un exemple, mais il y en a plein dans le code que tu as posté :

Dans la méthode Load, tu manipules des paramètres SQL. Cela devrait être fait dans la DAL et non dans la BLL. Ta BLL devrait manipuler un DTO, puis l'envoyer à la DAL. Ensuite la DAL alimente les paramètres SQL à partir du DTO.

C'est ce qui me fait dire que tu as fusionné les deux couches.

En général dans mes projets, je m'interdis certaines choses, comme par exemple le fait que telle couche ne doive pas référencer tel assembly. Par exemple la BLL ne doit pas référencer System.Data.SqlClient.dll. Pourquoi ? Parce que c'est le rôle de la DAL de l'utiliser, donc seule la DAL a le droit de le référencer. L'intérêt du DTO c'est de faire transiter les données d'une couche à l'autre, indépendament des traitements. La DAL va le "remplir" de données. Ensuite la BLL le récupère et elle va lui appliquer les règles métier ainsi que de la validation. Puis elle transmet le DTO à l'UI qui va gérer l'affichage.

Bien sûr, ça c'est si on veut rester proche de l'architecture multi-couches. Ca peut paraître un peu rigoureux. Sur un projet "simple", l'intérêt de la séparation des couches n'est pas forcément flagrant. Par contre dès que le projet se complexifie (beaucoup d'objets, plutôt complexes, avec de l'héritage/abstraction dans tous les sens, etc.) on le mesure nettement : le code est beaucoup plus clair.

[meziantou]

@meziantou : on dirait que tu as fusionné ta DAL et ta BLL (corrige-moi si je me trompe). Attention, ADO.NET n'est pas une couche en soit, c'est juste une API

Je prends un exemple, mais il y en a plein dans le code que tu as posté :

Dans la méthode Load, tu manipules des paramètres SQL. Cela devrait être fait dans la DAL et non dans la BLL. Ta BLL devrait manipuler un DTO, puis l'envoyer à la DAL. Ensuite la DAL alimente les paramètres SQL à partir du DTO.

C'est ce qui moi me fais dire que tu ne connais pas bien ADO.NET.
A quel moment dans mon code tu vois un paramètre SQL. Personnelement je n'en vois pas. Par contre il y a des DbParameter qui eux ne dépendent absolument d'aucun SGBD ou moyen de persistence. Tout dépend de ton provider.
Le paramètre est créé à partir d'une DbCommand qui elle même est créée à partir d'une DbConnection qui peut s'obtenir à partir d'un DbProviderFactory. Il n'y a donc aucune dépendance à un SGBD précis.

Tout ce qui est spécifique à la partie persistence se trouve dans le provider ADO.NET

BLL -> ADO.NET -> Provider ADO.NET (Sql Server, Oracle, CSV, Memory ou tout ce que l'on peut imaginer)

Pour moi la DAL correspond au provider ADO.NET et ADO.NET fait la liaison entre la DAL et la BLL. En aucun cas je ne fais de requête SQL directement dans la BLL, je demande simplement d'appeler une proc stock et le provider en fait ce qu'il veut (comme expliqué dans mon post précédent).

[youtpout978]

La dal est la couche qui s'occupe d'accéder à tes données donc dans dans ton cas les méthodes qui appel ta procédure stocké, ADO.NET n'est pas une dal mais un moyen de mettre en œuvre la DAL comme a dit DotNetMatt tu as fusionné ta BLL et ta DAL directement dans ta classe.
Ta classe peux être utilisé en l'état mais ne sera pas forcément compatible avec toutes les technologies .net, si tu dois l'inclure dans un projet silverlight, WP8, Windows RT tu auras surement toute ta classe à recoder.
Tu ne respectes pas aussi le principe d'encapsulation tu ne devrais pas pouvoir accéder au contenu de tes méthodes Load ,delete ... depuis le client.

[DotNetMatt]

A quel moment dans mon code tu vois un paramètre SQL. Personnelement je n'en vois pas. Par contre il y a des DbParameter qui eux ne dépendent absolument d'aucun SGBD ou moyen de persistence.

Effectivement, mais ce n'est pas facile de voir d'un coup d'oeil précisément le type des objets. Je m'étais fié au nom

En tout cas peu importe que tu dépendes ou non du SGBD, toujours est-il que BLL et DAL sont mélangées.

Pour moi la DAL correspond au provider ADO.NET et ADO.NET fait la liaison entre la DAL et la BLL. En aucun cas je ne fais de requête SQL directement dans la BLL, je demande simplement d'appeler une proc stock et le provider en fait ce qu'il veut (comme expliqué dans mon post précédent).

Je pense que tu as tout résumé, ADO.NET n'étant pas une couche mais une API... Cette perception est éronnée, ce qui provoque quelques incompréhensions entre nous (nous = youtpout978 + toi + moi).

Après attention on ne dit pas que ta façon d'avoir codé est mauvaise. On dit juste que par rapport aux principes de l'architecture N-Tiers (l'objet du topic), cette façon de faire ne nous semble pas adaptée, car elle n'en respecte pas tous les principes, et dans son dernier post, youtpout978 en a listé quelques uns.

[meziantou]

Effectivement, mais ce n'est pas facile de voir d'un coup d'oeil précisément le type des objets. Je m'étais fié au nom

En tout cas peu importe que tu dépendes ou non du SGBD, toujours est-il que BLL et DAL sont mélangées.

Je pense que tu as tout résumé, ADO.NET n'étant pas une couche mais une API... Cette perception est éronnée, ce qui provoque quelques incompréhensions entre nous (nous = youtpout978 + toi + moi).

J'ai toujours du mal à comprendre en quoi les 2 sont mélangés (oui je mets du temps à comprendre).
A un moment il faut bien que la BLL appelle la DAL. Que ce soit en utilisant ADO.NET ou autre chose (surement un appel de méthode dans votre cas) quelle est la différence (c'est ce point que je ne comprends pas). Dans le premier cas c'est le provider qui fait le taf. Dans le deuxième c'est ta méthode qui fait le taf (et qui appelera ADO.NET).
J'ai juste l'impression que vous ajoutez un intermédiaire là où il y en a déjà un (ça en fait donc 2).

Ta classe peux être utilisé en l'état mais ne sera pas forcément compatible avec toutes les technologies .net, si tu dois l'inclure dans un projet silverlight, WP8, Windows RT tu auras surement toute ta classe à recoder.

J'ai surement lu vos posts trop rapidement, mais pour moi le topic parlait de DAL et BLL et non de Web Service et d'UI donc je pensais être dedans. De plus je me suis laissé induire en erreur par les 3 premiers liens qui montraient l'utilisation d'ADO.NET donc pour moi on ne se situait pas dans une appli silverlight mais du côté du serveur. Désolé de mettre trompé.
Si tu souhaites partager le même code entre toutes les plateformes, il ne faut en effet pas utiliser cette méthode puisque, comme tu l'as dit, ça ne fonctionnera pas.
Forcément si on ne parle pas de la même chose, on ne peut pas se comprendre.

Tu ne respectes pas aussi le principe d'encapsulation tu ne devrais pas pouvoir accéder au contenu de tes méthodes Load ,delete ... depuis le client.

Il faut bien que le client puisse charger ou sauvegarder ses entités à un moment. S'il n'a pas accès à la méthode Load comment peut-il y arriver?



Encore une fois je ne cherche pas à avoir raison (j'ai même surement tord), je cherche juste à comprendre ce principe qui semble m'échapper. Peut-être qu'un exemple de code complet (DAL + BLL sans les mélanger ) pour une entité Customer (Id, Name) avec votre méthode m'aiderait à y voir plus clair et ainsi mieux cerner cette notion. Je vais donc continuer à vous lire en attendant de voir quelque chose de concret (ça à pas l'air simple à mettre en place en tout cas ).

[youtpout978]

Le faite justement d'avoir une architecture en couche permet par exemple de pouvoir exploiter différentes technologies sans rien modifier coté BLL-DAL seul l'UI change ou le contraire.

J'ai travaillé sur une appli client-serveur en winform, où donc coté client tu as une appli développé en windowsform et côté serveur un webservice WCF qui expose les méthodes de ta BLL, la BLL appel la DAL qui s'occupe de l'accès aux données en faisant appel à des Proc Stock pour des questions de performance.

Donc côté client tu as juste une référence aux objets qui sont transmis par le Webservice (tes POCO ou DTO) et l'interface correspondant au WebService, résultat côté client quand tu veux faire un Customer.Load tu appel la méthode Load de ton interface, tu ne sais pas ce qui se cache derrière étant donné que ce code est dans la BLL qui se trouve côté serveur, toi tu sais juste qu'il y a une méthode qui s'appel Load et qui te renvoie un customer.

Et rien n'empêche demain que le client ne soit plus une appli Winforms mais WPF par exemple ou autre et ça sans rien touché a ta BLL et ta DAL ou même changé de BDD en passant de SQL Server à Oracle ... sans touché à ta BLL et à ton appli côté client.

Si demain tu découvre un bug coté BLL tu auras juste à modifier le code de ta BLL et donc la redéployer sur le serveur sans redéployer les applis qui sont chez le client (ce qui peut correspondre à un simple changement de DLL).

[meziantou]

En gros tu as quelque chose de la sorte
DAL <- BLL <- UI
ou comme ça (selon les projets)
DAL <- BLL <- Web service <- UI
et tu dis que tu peux changer un élément sans impacter le reste.

C'est exactement ce que permet le code que j'ai présenté:
DAL = Provider ADO.NET
BLL = classe Customer
Web Service = Service WCF présenté
UI = ce que tu veux du moment que ça consomme du .NET ou le service WCF.

Si je change de base de données, il me suffit de changer de provider ADO.NET.
Si j'ai un bug dans la BLL, je modifie la classe customer et je déploie la dll
Je peux aussi passer de WinForms à WPF sans problème.

La seule différence concrete que je vois, c'est que apparement tu utilises la même entité côté serveur et côté client, et donc tu peux par exemple utiliser les règles de validation coté client. Est-ce que j'ai bon cette fois ?

[youtpout978]

Si tu modifie ta méthode Load dans ta classe Customer tu sera aussi obligé de redéployer ton appli client étant donné que cette classe est utilisé au sein de ton appli cliente aussi.
Et le provider ADO.Net n'est pas la DAL.
Sur un précédent post j'ai posté un lien qui montre l'exemple d'une appli MVC en Asp.Net.
Et même si tu ajoutes un WebService ça revient à dupliquer le code étant donné que t'auras à la fois la méthode Load dans ta classe Customer et dans l'interface du WebService, surtout que la méthode Load dans le Customer ne devrait pas être exploitable.
Et tu ne gères pas le cas où tu voudrais travailler avec une liste de Customer, tu ajouterais dans ta classe une méthode GetCustomers, DelCustomers .. qui serait sensé traiter une liste d'objet correspondant à elle même.

En faite tu aurais 5 projets un BLL, un DAL, un WebService(si t'en a besoin), un Entité (tes DTO ou POCO), un UI ...

Ta UI->WCF->BLL->DAL ou ta -> correspond en faite au transfert de tes entités, donc tous tes projets référence le projet entité et ensuite ta BLL ref ta dal le WebService ta BLL et ton UI l'interface du WebService.

[meziantou]

Je pense comprendre là où nos points de vue diverge. Mon entité Customer dans la BLL n'est pas la même que celle utilisé de l'autre côté du service.
Du coup si je modifie la méthode Load de cette entité Customer je n'ai que le serveur à modifier. L'entité côté client est elle aussi générée et communique avec le serveur WCF (pas par ADO.NET ). Côté client Customer.Load appelle le web service.

Et le provider ADO.Net n'est pas la DAL.

Qu'apporte une "DAL" en plus de ce que moi j'utilise? (ça par contre je n'ai toujours pas compris)

Et tu ne gères pas le cas où tu voudrais travailler avec une liste de Customer, tu ajouterais dans ta classe une méthode GetCustomers, DelCustomers .. qui serait sensé traiter une liste d'objet correspondant à elle même.

En fait, j'ai une classe CustomerCollection qui est une liste de Customer (un peu plus évoluée que simplement List<Customer>)

[Kikuts]

Si tu modifie ta méthode Load dans ta classe Customer tu sera aussi obligé de redéployer ton appli client étant donné que cette classe est utilisé au sein de ton appli cliente aussi.
Et le provider ADO.Net n'est pas la DAL.

Voilà

Dans ton cas, tu ne peux pas remplacer la DLL sans que ça te pète à la figure ^^

ET je pense aussi que tu mélanges DAL et BLL :p (bouh ! ^^)


Edit : Arg, tu as posté entre temps

[DotNetMatt]

Qu'apporte une "DAL" en plus de ce que moi j'utilise? (ça par contre je n'ai toujours pas compris)

Une DAL apporte pas mal de choses, parmis lesquelles (liste non exhaustive) :
- Possibilité de modifier la logique de la DAL indépendamment du reste (pas besoin de redéployer la BLL par exemple);
- Maximisation des performances si tu passes par une DAL "ordinale";
- Tu sais précisément ce qu'il se passe en son sein, ce qui n'est pas toujours le cas avec un ORM ou autre générateur de code;
- Possibilité de définir des traitements standards, et d'autres plus spécifiques (avec un ORM, si tu as des cas spéciaux, il peut être compliqué de les gérer vu que tu ne maîtrises pas tout);
- Meilleur découpage du code, en séparant la validation et la logique métier du code lié à la persistence (= encapsulation);
- Le code est réutilisable au sein de plusieurs applications;
- Etc....

A mon avis, si tu veux te forger ta propre opinion et approfondir le sujet, le mieux ça reste de reprendre les liens donnés pas Sankasssss dans le tout premier post de la discussion. Tu l'implémentes dans une petite appli console avec un projet pour chacune des couches, une DB derrière, tu vois ce que ça donne et tu joues avec

[meziantou]

Possibilité de modifier la logique de la DAL indépendamment du reste (pas besoin de redéployer la BLL par exemple);

Tu peux changer de provider ADO.NET via le fichier de configuration => Pas besoin de redéployer complètement la BLL (sauf si tu crées ton provider dans la même DLL que la BLL)

Maximisation des performances si tu passes par une DAL "ordinale";

Dans le troisième article (http://rlacovara.blogspot.fr/2009/03...ayer-part.html), il parle en effet des DAL "ordinale". Il faut vraiment avoir un besoin très spécifique pour faire cela.
La méthode SqlDataRecord.GetOrdinal dispose d'un cache "Nom de la colonne" - "Index", donc la différence de perf n'est pas énorme (mais je suis obligé d'admettre qu'il y en a une).

Donc dans ce cas OK, on peut faire une "DAL".

Tu sais précisément ce qu'il se passe en son sein, ce qui n'est pas toujours le cas avec un ORM ou autre générateur de code;

Possibilité de définir des traitements standards, et d'autres plus spécifiques (avec un ORM, si tu as des cas spéciaux, il peut être compliqué de les gérer vu que tu ne maîtrises pas tout);

Personnellement j'utilise des outils que je maitrise et qui me laisse faire ce que je veux. L'outil que j'utilise me laisse la main sur tout si je le souhaite. Si je veux changer une proc stoc, il n'y a aucun problème. Si je souhaite changer une méthode, c'est possible. Bref, j'ai le contrôle.
Je n'ai ainsi pas besoin de changer mon architecture pour combler les faiblesses d'un outil (en tout cas j'essaye).

Meilleur découpage du code, en séparant la validation et la logique métier du code lié à la persistence (= encapsulation);

Dans mon code la logique de validation est séparée du code de persistence.
Je comprends cependant que tu préfères faire Save(Id, Name, ...) au lieu d'un appel à ADO.NET. Ca donne l'impression d'être plus indépendant d'une base de données.

Le code est réutilisable au sein de plusieurs applications;

Le provider aussi. Peut-être ai-je mal compris l'argument. De toutes façon, en général tu réutilises la BLL entre les projets, pas trop la DAL.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
DAL <- BLL <- Appli 1
           <- Appli 2
           <- ...

A mon avis, si tu veux te forger ta propre opinion et approfondir le sujet, le mieux ça reste de reprendre les liens donnés pas Sankasssss dans le tout premier post de la discussion. Tu l'implémentes dans une petite appli console avec un projet pour chacune des couches, une DB derrière, tu vois ce que ça donne et tu joues avec

J'y travaille car j'ai encore du mal à voir l'intérêt (à par le cas très spécifique identifié ci-dessus). J'ai surtout l'impression d'ajouter un intermédiaire qui a pour but de rendre la BLL indépendante de la base de données choisies ou de mettre le code de persistence hors de la BLL. Cela est déjà assuré par ADO.NET.
Stockage - Provider - ADO.NET - "DAL" - BLL
Stockage - Provider - ADO.NET - BLL

[youtpout978]

Dans ton cas tu passes par un soft qui fait le boulot à ta place mais de toi même reproduire ce code pour chaque classe est très contraignant et peut très vite conduire à faire des erreurs.
Si tu es amené à le faire à la main tu iras plus vite à coder un model MVC qu'à reproduire ce que fait ce soft et ton architecture MVC sera plus facilement maintenable.

Il est normal que tu es du mal à voire ce qu'est la DAL étant donné que dans ce cas là ton ORM s'occupe de faire lui même l'accès aux donnée.
Après suivant le projet, les moyens, le temps, les intervenants, les performances visés tu pourras être amené à utiliser tel Soft, tel outil, tel architecture...

Il n'y a pas d'architecture parfaite mais il y en a des éprouvés qui font l'unanimité à tel point qu'il y a des modèles de projets qui sont basé dessus, le MVC en fait partie il existe ASP.Net MVC comme Struts en Java qui est aussi basé sur MVC.

Il y a d'autre design pattern comme MVP, il est toujours intéressant de les connaitre on peut être amené à les utiliser, à travailler dessus et savoir lequel sera le mieux à même d'être utilisé quand on crée un nouveau projet.

[meziantou]

Dans ton cas tu passes par un soft qui fait le boulot à ta place mais de toi même reproduire ce code pour chaque classe est très contraignant et peut très vite conduire à faire des erreurs.

Pourquoi faire à la main quelque chose qui peut être fait par quelqu'un d'autre automatiquement et sans erreur, surtout quand le code produit est pratique à l'usage et à mon sens bien architecturé.
A propos des générateur de code, la question à se poser est combien de temps passez vous à écrire la DAL et la BLL qui a la grande majorité du temps toujours la même tête, et combien de temps peut-on gagner à la générer (à condition que le générateur génère quelque chose de bien et autorise à étendre le code généré) ? Pour ma part le calcul est vite fait.

Cependant si je devais le faire à la main, je ferais surement quelque chose de semblable car c'est très agréable à utiliser.

Il est normal que tu es du mal à voire ce qu'est la DAL étant donné que dans ce cas là ton ORM s'occupe de faire lui même l'accès aux donnée.

Un "ORM" qui génère des proc stoc et utilise ADO.NET sans surcouche type EF ou concurrent, ça fait pas vraiment ORM au sens classique

Ce que moi j'appelle une DAL, c'est ce qui fait la liaison entre le stockage et la BLL. Est-ce juste ?

Il n'y a pas d'architecture parfaite mais il y en a des éprouvés qui font l'unanimité

Je ne peux pas dire mieux

J'ai juste montré une façon de faire que j'apprécie pour faire une BLL sans utiliser de DTO mais des objets (des données et des traitements). J'ai même montré (enfin je l'espère) qu'il y a une séparation entre ma BLL et la persistence et que ma BLL n'est pas reponsable de l'accès aux données. Je ne pensais pas déclencher un tel débat sur cette architecture et ainsi dériver du sujet initial. Bref, libre à vous de l'apprécier ou non.

En tout cas ça ne répond pas à la question, à savoir, où mettre les POCO et les DTO (dont personnellement je ne vois toujours pas l'intérêt pour les projets sur lesquels j'ai pu travailler, mais je ne dois surement pas travailler sur les bons projets ). Je vais attendre qu'une solution émerge pour peut-être y voir plus clair sur leur intérêt.

PS: serait-il possible d'expliquer le pouce rouge sur mon dernier message?

[youtpout978]

Il y a un paquet de raison pour lesquels les softs de génération de code ne sont pas utilisés:
- les décideurs n'en voit pas l'utilité
- ça fait peur aux personnes intervenant sur le projet qui préfère utiliser quelque chose qu'ils connaissent déjà
- souvent le soft est payant
- si le soft n'est plus supporté à l'avenir ça peut entrainer des problèmes
- et dans le cas où on a besoin d'une architecture aux petits oignons pour des questions de performance/sécurité ou autre

Voila autant de raison pour lesquels des softs indispensable pour certain ne sont pas utilisés par d'autre.

[meziantou]

Je ne vais pas rentrer dans le débat sans fin sur la génération de code. Je suis tout à fait d'accord sur le fait qu'il y a des cas où ça s'applique et d'autres non. A chacun de se faire sa propre idée, bien sûr selon son besoin.

[rv26t]

...je ne comprends donc toujours pas l'intérêt des DTO pour les performances.
...

N'abordons pas pour l'instant le coté réseau.

Quand on utilise les DTO, la lecture des données peut être ciblé.

En travaillant avec les DTO, on peut déterminer l'indice de la colonne dans le datareader pour ensuite accéder au reader par l'indice. Ainsi a chaque lecture de ligne on lit chaque colonne directement par son indice.
Sinon c'est le reader qui recherchera l'indice pour chaque colonne a chaque lecture de ligne.

On peut utiliser la méthode reader.IsDBNull avec l'indice (pour traiter tout de suite le cas).

Ensuite vu que l'on connait le type de la donnée, on peut utiliser les méthodes GetTYPE du reader (GetString, GetDateTime, ...), ce qui évitera un cast par la suite.

[meziantou]

Quand on utilise les DTO, la lecture des données peut être ciblé.

C'est à dire? Ca apporte quoi d'avoir un objet qui ne contient que des propriétés (http://skalp.developpez.com/traducti...e-dto-et-poco/) et rien d'autre pour lire des données ?

En travaillant avec les DTO, on peut déterminer l'indice de la colonne dans le datareader pour ensuite accéder au reader par l'indice. Ainsi a chaque lecture de ligne on lit chaque colonne directement par son indice.
Sinon c'est le reader qui recherchera l'indice pour chaque colonne a chaque lecture de ligne.

Point déjà évoqué précédemment avec les DAL ordinales. Comme je l'ai dis je ne suis pas sûr que la différence soit si énorme du fait du cache dans le provider (au moins celui de SQL Server).
Deuxièmement pourquoi ne pourrais-je pas le faire avec un objet tel que je l'ai présenté?

Cependant je suis intéressé par un benchmark si quelqu'un veut bien prendre un peu de temps pour le faire et voir le gain réel.

On peut utiliser la méthode reader.IsDBNull avec l'indice (pour traiter tout de suite le cas).

extrait de mon code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

this._name = CodeFluentPersistence.GetReaderValue(reader, "Customer_Name", (string)null)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    public static string GetReaderValue(IDataReader reader, string name, string defaultValue)
    {
      int ordinal = CodeFluentPersistence.GetOrdinal(reader, name); // call reader.GetOrdinal(name)
      if (ordinal < 0 || reader.IsDBNull(ordinal))
        return defaultValue;
      else
        return reader.GetString(ordinal);
    }

Comme tu peux le voir le cas DBNUll est tout de suite traité (avec l'indice).

Ensuite vu que l'on connait le type de la donnée, on peut utiliser les méthodes GetTYPE du reader (GetString, GetDateTime, ...), ce qui évitera un cast par la suite.

C'est à dire qu'il y a des cas où tu ne connais pas le type des objets que tu traites ?

[youtpout978]

C'est à dire qu'il y a des cas où tu ne connais pas le type des objets que tu traites ?

Non c'est juste que sinon tu peux te retrouver à faire ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int id= (int)reader["id"];

[rv26t]

@meziantou
Mon précédant message était pour resituer l'utilisation des DTO par rapport à une programmation plus simple et directe. (dataset, datatable, Fill, voire lecture directe du reader) J'aurai du le préciser.
Ce n'est pas du tout une critique de ton code ou une comparaison à celui-ci.

Mais pour te répondre.
Le DTO peut être affecté à une propriété d'un objet (ne détaillons pas tout nous allons troller)
J'avais bien vu l'appel de ta méthode GetReaderValue(reader, "Customer_Id", ((int)(-1)));Par contre le code de celle-ci n'y était pas [Edit]Je veux dire présenté comme 2ème bout de code[/edit], je ne pouvais pas savoir que tu utilisais les ordinaux.
Bien sur que je connais le type de mes données (un exemple d'utilisation a été indiqué, sur ce qui peut être fait).

Dans une programmation plus directe, sur la lecture d'un ensemble important de lignes la différence n'est peut être pas négligeable.
Mais garde à l'esprit que je voulais parler des DTO par rapport à une programmation plus directe.