Architecture de couche d'accès aux données (DAL) de hautes performances - Partie 1, version VB.NET du tutoriel traduit par Hervé Taraveau

Membre émérite

Le 30/12/2013 à 19:06

D’un côté, certains préfèrent tout écrire à la main en utilisant directement ADO.NET sans surcouche. D’un autre côté les fervents défenseurs des ORM. En gros d’un côté on aime faire de la plomberie alors que de l’autre non

. Personnellement je n'aime pas la plomberie mais je n'utilise pas pour autant un ORM.

Je tenais juste à présenter un produit avec une approche différente : CodeFluent Entities. En gros comme Entity Framework, on part d’un modèle représentant des entités, des énumérations, des propriétés, des méthodes, des règles, des vues, etc. (on peut modéliser un peu plus de concepts qu’EF (le document date de 2012 mais beaucoup de choses restent vraies)). On ajoute ensuite des producteurs dont le but est de générer le code (SQL Server, Oracle, PostgreSQL, C#, VB.NET, WCF, Proxy WCF, ASP.NET, etc.). Tout le code généré est statique (Procédures stockés, code d’accès aux données…) et pour l'accès aux données, seuls des procédures stockées et ADO.NET sont utilisés, ce qui devrait plaire à rv26t

.
A vrai dire il y a une très légère surcouche nommée CodeFluentPersistence dont le but est de masquer les différences entre les différents SGBD, notamment au niveau des paramètres (par exemple certains utilisent @param, d'autres :param) ou des erreurs (duplicate, concurrence). Bref ça reste très très léger.

On a donc les avantages d’une approche Model-First tout en ayant au final un code totalement statique et facilement lisible (donc debuggable au besoin). Pour ceux qui se demandent quels sont les avantages du model first.

Pour ceux qui veulent refaire un semblant de CodeFluent Entities avec EF (oui on en est encore assez loin), vous pouvez regarder le blog de Matthieu Mezil et son WAQS (c’est un fan absolu d'EF et des T4).

Il ne faut pas non plus oublier un problème assez important vis à vis d'Entity Framework : le travail en équipe est un véritable calvaire !

CodeFluent Entities gèrent cela sans trop de problème. Le modèle peut être découpé en autant de fichiers que nécessaire (un par entité, un par namespace, ou autre), alors qu'avec EF on a un fichier EDMX pour tout le modèle. Au niveau du designer on peut spécifier quels éléments doivent être affichés sur chaque surfaces (contrairement à EF on peut avoir plusieurs surfaces). Cela permet également de travailler avec de gros modèle.

4

0

Kropernic

Expert confirmé

Le 24/12/2013 à 9:55

Envoyé par Immobilis

Salut,Ce type de clef est plutôt une contrainte d'intégrité qu'une vrai clef (en général dangereusement basée sur un concept fonctionnel). Mais bon ce n'est pas le sujet du topic.

Ce type de clef découle d'une modélisation respectant les règles de gestion. Je suis d'accord avec toi, ce n'est pas l'objet du topic. Néanmoins, si CodeFirst ne le permet pas, c'est pour moi déjà un point éliminatoire.

Envoyé par Immobilis

Oui. Mais ton implémentation de DAL ne fait pas tout ça non plus.
Ce n'est pas le rôle d'un ORM. Un ORM ne remplace pas le travail d'un administrateur de base de données. Tu te trompes sur l'usage.

Tu sembles réfractaire... Cela m'arrive aussi. Je te suggère d'essayer

A+

Non, ma DAL ne fait pas cela en effet. Mais elle ne crée pas la DB non plus.

Avec Code First, c'est en fait la DB qui s'adapte au code. Or je crois profondément que cela de devrait jamais être le cas. Pour tout projet impliquant de stocker de l'information, je pense que la première chose à faire est de mettre à plat toute l'information de l'univers concerné par le projet et de voir/comprendre comme elle s'organise. Une fois la DB correctement normalisée et après vérification de toutes règles de gestion par la MOA, alors seulement, il est temps de penser à la partie software du projet.

Les bases d'un projet d'information de gestion SONT les données (et par conséquent, la DB). Une DB fortement normalisée et avec les contraintes appropriées permettra la détection automatique d'une tonne de "bugs" en phase de dev/test. Il est si facile d'oublier de faire une vérification avant d'insérer une ligne dans une table qui n'aurait pas y être.

Bref, je vais m'arrêter là, je crois qu'on a compris que je place les données avant tout dans un projet en impliquant.

Je suis purement programmeur de formation mais dans la boîte où je suis, on s'occupe de tout du début à la fin. Ce qui m'a fait prendre conscience de l'importance incommensurable d'une base de données correctement modélisée/normalisée. Une fois cela établi, le développement de l'application est grandement facilité. Il suffit de suivre les rails posées par la DB.

3

0

Immobilis

Expert éminent

Le 19/12/2013 à 9:47

Envoyé par Kropernic

Lourdeur de maintenance ???

Ben oui, L'ajout d'un champ implique une intervention dans le code que je trouve très lourde et génératrice de bug. Mais bon comme tout c'est un choix.

Envoyé par Kropernic

J'aime avoir le contrôle "absolu" sur la moindre chose que je fais.

C'est une illusion dans la mesure où tu utilises déjà un Framework qui fait 99,99% du boulot. A moins de coder en langage machine tu ne contrôles pas tout.

Envoyé par Kropernic

Je n'ai encore jamais utilisé d'ORM

Ceci explique peut-être cela

A+

2

0

Immobilis

Expert éminent

Le 19/12/2013 à 12:18

Envoyé par Kropernic

Tout ce qu'il y a à faire, c'est d'ajouter la propriété dans le DTO et de gérer son assignation dans le parser...

Je comprend bien sauf que dans cette phrase qui a l'air simple tu réalises des opérations lourdes (à mon avis): ajout de propriétés en cascade, des noms de colonnes en dur, des conditions, des initialisations. En fait ça me rappelle des méthodes que j'utilisais en 2006...
Sinon, tu as oublié la mise à jour du constructeur du DTO (alors que le Framework instancie lui-même les types "valeur"

, de la méthode PersonDb.SavePerson pour lequel il faut aussi mettre à jour le paramètre. Tu vois, deux oublis, pas si simple.
Une autre raison pour laquelle je n'utilise plus ce système est que je ne vois plus où est l'avantage (le gain) à faire des méthodes du type GetMonObjectByXXXXXX(string). C'est bien plus pratique/fiable d'utiliser une expression lambda sur un repository qui va adapter la requête SQL.
De plus, le gain de temps de l'ordre de la milliseconde est négligeable par rapport au reste de l'exécution de la page. En proportion ok c'est deux fois plus peut-être mais cela reste insignifiant si tu ne fais pas de l'aéronautique.

Envoyé par Kropernic

Pareil ici. J'utilise les briques du framework et je ne fais pas appel à un entrepreneur (ORM).

Entity Framework fait parti du Framework .NET. Pour moi tu moules tes parpaings alors qu'on en trouve de très bons sur le marché. Le seul entrepreneur auquel tu fais appel c'est ADO .NET auquel tu délègues la récupération de tes données auprès de la base (le sable, l'eau, le ciment). L'assemblage, la création de l'objet, c'est toi qui le fais.

Envoyé par Kropernic

avant de revenir à mes requêtes/procédures stockées écrites moi-même.

L'utilisation de procédures stockées et d'un ORM est effectivement la meilleure solution.
A+

2

0

rv26t

Modérateur

Le 19/12/2013 à 10:21

Envoyé par Kropernic

... mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés, ...

Justement, j'ai fait une petite modif de ce coté. J'essayerais de faire un billet.

J'ai rendu la méthode générique (note : je ne parle pas des paramètres de la requête pour GetSingleDTO que je passe de façon particulière, ce n'est pas le but du sujet)

Code :

Sélectionner tout

1
2
3
4
5
6
7
8
9
10
11
''' <summary>DTOParserFactory : fabrique pour obtenir un objet analyseur (parser).</summary>
''' <remarks>Les méthodes sont déclarées en Shared.</remarks>
Public NotInheritable Class DTOParserFactory

    ''' <summary>Fabrique générique d'analyseur, (Parser) Cré une instance de classe concrête quelconque de type « DTOParser ».</summary>
    ''' <typeparam name="T">Un type de classe héritant de DTOParser abstraite.</typeparam>
    ''' <returns>Une instance de la classe DTOParser spécifique demandé par l'application utilisatrice.</returns>
    ''' <remarks>Méthode générique. Performance. Déclarée en Shared.</remarks>
    Public Shared Function FabriqueClasse(Of T As {New})() As T
        Return New T
    End Function

Et dans ma nouvelle méthode GetSingleDTO qui se présente ainsi

Code :

Sélectionner tout

1
2
3
4
5
6
7
8
    ''' <summary>Lit une ligne de données renvoyé sous forme d'une instance de classe définie par l'appelant.</summary>
    ''' <typeparam name="T">Type de classe analyseur qui sera utilisé pour créer un DTO léger recevant les données.</typeparam>
    ''' <param name="Requete">La requête de sélection.</param>
    ''' <returns>Une instance de classe DTO léger d'un ensemble ligne de données.</returns>
    ''' <remarks>Méthode générique ne connaissant pas le type de classe analyseur en entrée. 
    ''' Une fabrique générique renvoie une instance de cette classe analyseur,
    ''' une méthode de cette instance retourne une instance DTO léger contenant l'ensemble d'une ligne de données.</remarks>
    Public Function GetSingleDTO(Of T As {New})(ByVal Requete As String) As DTOBase

Je fais un appel à la fabrique de cette façon (dans GetSingleDTO)

Code :

Sélectionner tout

parser = DTOParserFactory.FabriqueClasse(Of T)()

Pour un ensemble d'info (de DTO) j'ai donc une méthode qui renvoi une liste

Code :

Sélectionner tout

1
2
    ''' <summary>Lit plusieurs lignes de données renvoyé sous forme d'une liste d'instance de classe définie par l'appelant.</summary>
    Public Function GetListDTO(Of T As {New})(ByVal Requete As String) As List(Of DTOBase)

Cela fonctionne très bien, mais il me reste un petit souci avec le parser que je dois déclarer de type object, je préférerais arriver à le typer.

Voilà, simplement pour dire que l'on peut, comme l'indique Kropernic, puiser des idées et adapter à ses besoins.
Les messages arrivent plus vite que mes réponses.

1

0

plume13

Membre confirmé

Le 24/12/2013 à 17:45

Bonjour à tous, j'ai lu avec intérêt vous posts et les tutos cités. Je ne connaissais pas CodeFirst et c'est vrai que cela a l'air simple et pratique. Les développeurs n'ont plus besoin de s'y connaître en BDD. Le rêve quoi !
Sauf que j'ai du mal à croire que ce soit aussi magique... Je suis plutôt de l'avis de Kropernic sur le fait que le coeur d'un logiciel de gestion, c'est la base de données, et qu'il est préférable de garder la main dessus et que peu de personnes puissent modifier son schéma.
Cependant, j'utilise EF en Database-First avec modèle T4 d'objets POCO et j'en suis satisfaite : je garde la main tout en m'évitant l'écriture de code d'ajout/modification/etc. Par contre, je fais bien attention à ce que j'écris en linq, histoire de pas me retrouver avec des requêtes Sql de 300 lignes.

Cela dit, j'essaierai un jour pour voir ce que ça donne vraiment, je pourrais être surprise

1

0

Immobilis

Expert éminent

Le 25/12/2013 à 12:11

Envoyé par Kropernic

Ce type de clef découle d'une modélisation respectant les règles de gestion.

C'est justement ce qu'il faut éviter. Les règles de gestion métier sont changeantes, incomplètes, dépendantes des méthodes de travail. Cela fait porter un risque sur l'intégrité de la base de données. A mon avis, les clefs ne devraient être que des identifiants uniques auto-générés (guid, entier). L'intégrité des données peut être garanties par d'autres moyens triggers, contraintes, ...

Envoyé par Kropernic

Avec Code First, c'est en fait la DB qui s'adapte au code.

Je ne dirai pas ça comme ça mais plutôt le modèle (le terme est important) est créé via une IHM de design dans Visual Studio. Le produit obtenu est un script SQL.

Sinon, les approches modèle et code first sont similaires. Dans le premier cas, je dirai qu'on se laisse guider par un assistant et comme en général le model est souvent très proche de la structure de la base (ou inversement), c'est une excellente entrée en matière.

Une fois la DB correctement normalisée et après vérification de toutes règles de gestion par la MOA

Si le modèle se base sur des métadonnées cela devient difficile à montrer. Dans les cas "normaux", cela se fait aussi très bien avec EF et Visual Studio.

Envoyé par plume13

j'utilise EF en Database-First avec modèle T4 d'objets POCO et j'en suis satisfaite

Faudrait que j'essaye ça aussi.

Quelque soit l'approche c'est surtout une question d'affinité avec les outils de développement. Il n'y a pas UNE façon de développer.

A+

1

0

rv26t

Modérateur

Le 27/12/2013 à 23:30

@Kropernic

Envoyé par Kropernic

mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés...

Envoyé par rv26t

Justement, j'ai fait une petite modif de ce coté. J'essayerais de faire un billet.

J'ai rendu la méthode générique (note : je ne parle pas des paramètres de la requête pour GetSingleDTO que je passe de façon particulière, ce n'est pas le but du sujet)

Voici la méthode GetListDTO avec les classes de travail générique en paramètres (T pour le type de classe parser, V pour le type de classe DTO qui constituera la liste) pour répondre à toutes construction de liste de DTO de façon générique. (mais avec des éléments typés) (GetSingleDTO idem)

Code :

Sélectionner tout

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    ''' <summary>Lit plusieurs lignes de données renvoyé sous forme d'une liste d'instance de classe DTO définie par l'appelant.</summary>
    ''' <typeparam name="T">Type de classe analyseur qui sera utilisé pour créer un DTO léger recevant les données.</typeparam>
    ''' <typeparam name="V">Type de classe DTO léger recevant les données.</typeparam>
    ''' <param name="Requete">La requête de sélection.</param>
    ''' <returns>Une liste d'instances de classe DTO pour l'ensemble de ligne de données.</returns>
    ''' <remarks>Méthode générique ne connaissant pas le type de classe analyseur en entrée, ni le type de DTO.
    ''' Une fabrique générique renvoie une instance de cette classe analyseur, une méthode de cette instance (PopulateDTO) retourne une instance DTO léger contenant l'ensemble d'une ligne de données.
    ''' Une boucle permet la lecture de toutes les lignes et d'alimenter la liste retournée. Une liste de DTO correspondant au type (V) (passé en paramètre) est ainsi constituée, et renvoyée.</remarks>
    Public Function GetListDTO(Of T As {New}, V)(ByVal Requete As String) As List(Of V)
        Dim ListeDTO As List(Of V) = New List(Of V)
                    ' suite code ...
                    ' ...
                    parser = DTOParserFactory.FabriqueClasse(Of T)()
                    ' suite code ...
                    ' ...
                    Return ListeDTO

Le paramètre peut rester (ByRef command As SqlCommand) comme dans le tuto au lieu de la requete

1

0

rv26t

Modérateur

Le 13/01/2014 à 14:42

@meziantou
Merci pour ces infos (désolé pour le temps de réponse)
Connaître d'autres solutions telle que celle que tu présentes est très intéressant.

Cela permet de choisir la meilleure approche suivant le type de projet.

A ce titre il me semble judicieux d'indiquer aussi l'existance de Dapper qui est vraiment très léger et permet une approche très simple.

1

0

Immobilis

Expert éminent

Le 19/12/2013 à 1:02

Salut,

Intéressant mais les références citées sont un peu anciennes (2008 et 2009). Outre l'architecture tu aurais pu refaire des tests avec les derniers Framework, non?

Personnellement, compte tenu de la lourdeur de la maintenance d'une telle architecture, en dehors d'une course à la microseconde, il y a peu de chance que je revienne à cette façon de faire.

A+

0

Identifiez-vous

Créer un compte

Architecture de couche d'accès aux données (DAL) de hautes performances - Partie 1

Version VB.NET du tutoriel traduit par Hervé Taraveau

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

Architecture de couche d'accès aux données (DAL) de hautes performances - Partie 1 Version VB.NET du tutoriel traduit par Hervé Taraveau

Architecture de couche d'accès aux données (DAL) de hautes performances - Partie 1

Version VB.NET du tutoriel traduit par Hervé Taraveau