Discussion :

[rv26t]

bonjour,

Cette discussion est destinée à recueillir vos commentaires sur l'article « Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 1 » et des Data Ttransfert Object (DTO).
Traduction de l'article « High Performance Data Access Layer Architecture Part 1 » de M. Rudy Lacovara.

DTO, DAL, BLL… Tout le monde s'en sort ? Pas si sûr !
Voici le premier chapitre d'un article qui vous aidera à comprendre cette architecture et ses concepts-clés.
Dans cette première partie, nous allons nous intéresser à l'architecture globale de la DAL et l'utilisation des DTO pour transférer des données entre les différentes couches de l'application.
Nous allons aussi voir la mise en pratique de ces concepts à l'aide d'une classe PersonDB qui contiendra l'ensemble de nos méthodes d'accès aux données permettant d'obtenir et de sauvegarder les données d'une entité « personne ».

Cette série de trois articles décrit comment écrire une couche d'accès aux données de hautes performances.
Lien sur les discussions des autres articles : Discussion sur la partie 2, Discussion sur la partie 3

Bonne lecture.

[meziantou]

J'ai quelques remarques:
- Pourquoi passer les arguments en ref :

Code :

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

protected static T GetSingleDTO<T>(ref SqlCommand command) where T : DTOBase

- Pourquoi utiliser SqlConnection, SqlDataReader, etc. au lieu de IDbConnection, IDataReader, etc.

Code :

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

if (reader.HasRows) { reader.Read();

Pourquoi ne pas directement faire

Code :

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

if(reader.Read())

[rv26t]

Bonjour meziantou

Merci pour tes remarques. (concerne la partie 2)

Avant tout, je préfère rappeler qu'il s'agit d'une traduction que j'ai faite, et je ne connais donc pas forcement ce que pense l'auteur (M. Lacovara) et pourquoi il a codé ainsi.
Mais nous pouvons bien sur réfléchir sur ce qu'il a fait et sur d'autres approches différentes. (C'est toujours intéressant, cela permet de progresser.)

J'ai quelques remarques:
- Pourquoi passer les arguments en ref :

Code :

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

protected static T GetSingleDTO<T>(ref SqlCommand command) where T : DTOBase

Ici, c'est pour ne pas faire une copie locale de command dans la méthode GetSingleDTO, ce qui me semble relativement courant.

- Pourquoi utiliser SqlConnection, SqlDataReader, etc. au lieu de IDbConnection, IDataReader, etc.

Je ne saurai te répondre directement.
Personnellement, j'ai créé une bibliothéque DAL générique qui me sert pour mes nouvelles appli. J'y ai intégré les DTO, aspect qui m'intéressait. J'ai transformé la méthode GetSingleDTO pour justement ne plus avoir de paramètre de type command.
Donc une approche avec IDbConnection, IDataReader... est, me semble-t-il, parfaitement envisageable.
J'avoue que je ne sais pas si l'utilisation d'interface peut avoir un impact sur les performances. (Le but étant d'être performant. Donc à voir sur des lectures nombreuses avec GetDTOList)
En tout état de cause pour avoir une réponse précise par rapport aux choix effectués par l'auteur tu peux poser la question sur son blog concernant l'article 2 : « High Performance Data Access Layer Architecture Part 2 ».

Code :

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

if (reader.HasRows) { reader.Read();

Pourquoi ne pas directement faire

Code :

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

if(reader.Read())

Pour la méthode GetSingleDTO effectivement (peut être pour une meilleure lisibilité du code, l'impact d'un test étant négligeable). Par contre dans GetDTOList c'est utile puisque l'on effectue des traitements préparant la lecture.

Espérant avoir pu répondre en partie à tes remarques.

[Kropernic]

Hello,

C'est vrai que quand j'ai découvert ces articles, je ne m'étais pas trop posé de question à l'époque (étant un noob en POO, ça fonctionnait bien alors j'ai dit amen ).

Maintenant, à la vue des questions soulevées par meziantou, je m'interroge également.

Concernant le passage par référence :
Hervé donné une piste. Maintenant, à moins d'avoir une boucle qui, pour une raison x ou y, irait exécutait un certain nombre de fois la méthode, je ne vois pas trop le problème de faire un passage par valeur.
Je remarque aussi que dans la méthode GetSingleDTO (idem pour GetDTOList), on ferme et libère la connexion. Alors je ne sais pas vous mais perso dans mes classes DAL, ça donne quelque chose du genre :

Code :

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

1
2
3
4
5
6
7
8
 
Dim obj as DTO.MonObjet
Using cmd as SqlCommand = CreateSpCommand("STORED_PROCEDURE_NAME")
    cmd.Parameters.Add(CreateParameter("@PRM_NAME", prm_value))
 
    obj = GetSingleDTO(Of DTO.MonObjet)(cmd)
End Using
Return obj

A la destruction de l'objet command par le End Using, la connection est automatiquement fermée et libérée non ?

Concernant les types pour les objets DB (SqlConnection, SqlCommand, etc.) :
Pour avoir lu d'autre de ces articles, je sais que l'auteur travaille avec SQL SERVER. Je pense qu'il ne faut pas chercher plus loin. Mais voir une implémentation plus générique m'intéresserait. Je suis d'ailleurs en total désaccord avec lui quand, dans un autre article, il explique qu'il ne perd plus son temps à faire une couche DAL séparée et qu'il mixe tout dans la BLL car, après tout, changer de DB n'arrive que très rarement dans la vie d'un développeur.

Concernant If reader.HasRows() :
Personnellement, je préfère avoir ce test en plus. Je trouve cela plus lisible. Il ne faut pas perdre de vue que, lorsque nous programmons, ce ne sera pas forcément nous qui devront maintenir le code. Et puis ça me rappelle mes cours de méthodologie où mon prof répétait sans cesse : "Je prépare, j'utilise". Donc ici, on prépare le reader (on vérifie s'il contient des données) et on l'utilise ensuite (on lit les données qu'il contient).


Comme l'a souligné Hervé, il n'a fait qu'une traduction. Il n'est donc pas à blâmer (personne ne l'est en fait je crois). Mais ne perdons pas de vue que l'auteur n'est pas un dieu non plus. Il est donc fort possible que ce qu'il a partagé avec nous sur son blog puisse être sujet à amélioration. Je vois plus ces articles comme une bonne base de travail sur laquelle s'appuyer pour progresser.

[meziantou]

SqlCommand est une classe et non une structure, je ne comprend donc pas le gain de performance en utilisant ref.
http://stackoverflow.com/questions/8...ing-same-types
http://stackoverflow.com/questions/3...formance-c-net


Pour l'utilisation de Using(...) ça ne change pas grand chose: le using va être transformé en

Code :

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

try {} finally {obj.Dispose();}

Le dispose ferme la connexion. Le résultat est le même (même si moi aussi je préfère utiliser using)

Je suis d'ailleurs en total désaccord avec lui quand, dans un autre article, il explique qu'il ne perd plus son temps à faire une couche DAL séparée et qu'il mixe tout dans la BLL car, après tout, changer de DB n'arrive que très rarement dans la vie d'un développeur.

Je suis plutôt d'accord avec sa façon de faire, à condition de n'utiliser que des procédures stockées (D'ailleur j'avais déjà défendu cette vision dans un autre post qui parlait DAL, DTO, POCO, et je ne sais plus quels acronymes). En effet même si tu changes de base de données, la couche d'accès reste la même à 1 ou 2 détails près (par exemple certains SGBD ne supporte pas les noms de plus de 30 caractères)

Comme l'a souligné Hervé, il n'a fait qu'une traduction. Il n'est donc pas à blâmer (personne ne l'est en fait je crois)

Je ne le blâme pas, j'essaye juste de comprendre les choix techniques.
De plus il n'est pas interdit d'annoter la traduction, ce qui a mon sens ajouterais une vraie plus-value, surtout que le traducteur a fait des modifications pour créer sa DAL. Rien ne l'empêche d'expliquer ces modifications et pourquoi il les a faites.

[rv26t]

Comme l'a souligné Hervé, il n'a fait qu'une traduction. Il n'est donc pas à blâmer (personne ne l'est en fait je crois).

Je ne le blâme pas, j'essaye juste de comprendre les choix techniques.
De plus il n'est pas interdit d'annoter la traduction, ce qui a mon sens ajouterais une vraie plus-value, surtout que le traducteur a fait des modifications pour créer sa DAL. Rien ne l'empêche d'expliquer ces modifications et pourquoi il les a faites.

Ne vous faites pas de soucis, je ne me sens pas blâmé. (comme je l'ai indiqué au début, je ne connais pas forcément la raison de certains choix de l'auteur)

J'ai simplement fait une traduction le plus fidèle possible des articles.

Je préférais laisser les lecteurs se faire leurs propres idées, et ne pas orienter leurs avis par des choix personnels. (Après la discussion est là pour échanger)
_______________________

Je travaille sur de petits projets. (Donc j'essaye d'anticiper le fait qu'un jour ma DAL pourra utiliser d'autres BDD.) Précision je travaille avec VB.

J'avais déjà créé ma DAL qui pouvait me renvoyer des DataSet, des DataTable, ou des info plus ciblées (une info avec ExecuteScalar, un dictionnaire, ...). Mais pour un ensemble de données typées, je retournais un jeu de données de type DbDataReader avec lequel je travaillais hors de ma DAL générique — une partie DAL appli — donc réécriture de code sensiblement le même sur le principe (il existe d'ailleur un article abordant le sujet de ce problème de réécriture fastidieux).

L'article m'a permit de trouver ce que je cherchais, les DTO.

J'ai intégré dans ma DAL que les méthodes GetSingleDTO et GetListDTO (pas le reste) en les transformant (pour utiliser les requêtes paramètrées). En créant une bibliothèque DTO de référence (DTOBase, DTOParser, et en transformant DTOParserFactory en une fabrique générique — sinon les méthodes GetSingleDTO et GetListDTO étaient inutilisables)

Il s'agit donc dans mon cas d'une utilisation personnelle très ciblée. Et je me suis servi de ces articles pour compléter l’existant. (voilà pour les explications)
_______________________

Ayant traduit les articles pour mes travaux personnels, je me suis dit que cela pouvais être utile à d'autres. Echanger des idées pour apprendre...


[Edit] Vu qu'il n'y a pas eu d'autres messages, je complète ma réponse.

SqlCommand est une classe et non une structure...

Exact, j'ai été imprécis.
Il s'agit donc de ne pas faire une copie locale de la référence à command.
Je n'ai pas d'idée sur les performances. (Je vais regarder tes liens)
Vu l'utilisation de command qui est faite dans la méthode je ne vois pas ce qui pourrai orienter le choix du passage de paramètre par valeur ou par référence. (perso, je ne passe plus un paramètre de type command à mes méthodes GetSingleDTO et GetListDTO mais une requête, j'ai profondément modifié leurs utilisations pour les rendre très générique.)

Pour ceux qui souhaite une petite explication sur le passage de paramètre voir ce tuto : Passage de paramètres en C#