IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Modérateur

    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 722
    Par défaut Architecture de couche d'accès aux données (DAL) de hautes performances — partie 1. (et les DTO)
    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 Transfer 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.
    Traductions d'articles :
    La mémoire en .NET - Qu'est-ce qui va où ?
    Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
    N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.

  2. #2
    Expert confirmé
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Par défaut
    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+
    "Winter is coming" (ma nouvelle page d'accueil)

  3. #3
    Membre expérimenté
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Par défaut
    Lourdeur de maintenance ???

    C'est l'architecture que j'utilise pour chacun de mes projets et, mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés, la maintenance n'est pas lourde du tout.

    Tout est justement très clair je trouve. Tout ce qui concerne l'accès au données se trouve dans la DAL. Tout ce qui concerne les contraintes métiers (validation, traitement, etc.) se trouve dans la BLL. Et elle communique entre elles via les DTO. Rien de plus simple.

    C'est propre et rigoureux. Et puisque c'est ainsi, la maintenance est donc très simple (A partir du moment où l'on comprend bien où chaque chose doit se mettre. C'est vrai qu'au tout début, j'avais un peu de mal).

    Bien sûr, comme tout pattern (ce n'est p-e pas le bon mot mais tant pis), ce n'est qu'un guide de base. Libre à chacun de l'adapter suivant ses besoins. Par exemple, et je sais que ça va faire hurler certains, j'ai adapté tous mes DTO en leur ajoutant une méthode ToString.
    Certains diront qu'alors ce n'est plus un DTO et que je sors de cette architecture mais qu'importe. C'est mon besoin d'avoir cette méthode.

    Quant au pourquoi j'utilise cette architecture, c'est simplement car je suis un paranoïaque du contrôle de mon code. J'aime avoir le contrôle "absolu" sur la moindre chose que je fais. Je n'ai encore jamais utilisé d'ORM mais d'après tous les articles que j'ai pu lire à leur sujet (et ça en fait quelques uns), c'est l'ORM qui s'occupe de faire la requête SQL pour récupérer les objets. Comment puis-je alors m'assurer que cette requête est correctement écrite (de manière optimale afin d'utiliser les bons indexes) et qu'elle me retournera bien ce que j'ai besoin et uniquement ce que j'ai besoin ?

    My 50 cents...

  4. #4
    Expert confirmé
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Par défaut
    Citation Envoyé par Kropernic Voir le message
    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.
    Citation Envoyé par Kropernic Voir le message
    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.
    Citation Envoyé par Kropernic Voir le message
    Je n'ai encore jamais utilisé d'ORM
    Ceci explique peut-être cela

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  5. #5
    Membre expérimenté
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Par défaut
    Citation Envoyé par Immobilis Voir le message
    Ben oui, L'ajout d'un champimplique 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.
    J'imagine que par champ, tu veux dire une colonne dans une table de la DB. 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... Pour le reste, il n'y a pas plus de travail qu'avec un ORM.

    Citation Envoyé par Immobilis Voir le message
    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.
    Dans le genre argument en carton... Une petite comparaison (caricature). Je souhaite construire une maison mais je veux le faire moi-même car je veux être sûr d'avoir exactement ce que je veux. Je vais donc acheter des briques (et du ciment) et je me mets au boulot. Je ne fabrique pas les briques moi-même...

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

    Citation Envoyé par Immobilis Voir le message
    Ceci explique peut-être cela
    Ce n'est pas parce que je n'en ai jamais utilisé pour un projet que je ne sais pas comment cela fonctionne. Ce ne sont pas les tutos et articles qui manquent à leur sujet. Et j'ai brièvement testé EF sur un projet trash (je ne sais plus quelle version c'était) avant de revenir à mes requêtes/procédures stockées écrites moi-même.

  6. #6
    Modérateur

    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 722
    Par défaut
    Citation Envoyé par Immobilis Voir le message
    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?
    En fait j'ai surtout été intéressé par la partie 3 (l'utilisation de DTO), et dans une moindre mesure la partie 1. Mais je ne pouvais pas seulement traduire juste une partie, j'ai fait la série.
    Je n'utilise pas oracle donc difficile de refaire des test.
    J'ai 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 créé une bibliothéque DataTrnsfertObject). J'ai transformé la méthode GetSingleDTO pour justement ne plus avoir de paramètre de type command. Après, je fais de petit projet.

    Comme l'indique Kropernic, on peut utiliser certaines idées ou principes selon les besoins.

    Citation Envoyé par Immobilis Voir le message
    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.
    L'auteur indique bien dés le début que la solution proposé est seulement pour certain cas ou la performance est la priorité.
    Traductions d'articles :
    La mémoire en .NET - Qu'est-ce qui va où ?
    Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
    N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.

  7. #7
    Modérateur

    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 722
    Par défaut
    @Kropernic
    Citation Envoyé par Kropernic Voir le message
    mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés...
    Citation Envoyé par rv26t Voir le message
    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 - Visualiser dans une fenêtre à part
    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
    Traductions d'articles :
    La mémoire en .NET - Qu'est-ce qui va où ?
    Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
    N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.

  8. #8
    Membre Expert Avatar de meziantou
    Homme Profil pro
    autre
    Inscrit en
    Avril 2010
    Messages
    1 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : autre
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2010
    Messages : 1 223
    Par défaut
    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.

  9. #9
    Modérateur

    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 722
    Par défaut
    @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.
    Traductions d'articles :
    La mémoire en .NET - Qu'est-ce qui va où ?
    Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
    N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.

  10. #10
    Modérateur

    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 722
    Par défaut
    Citation Envoyé par Kropernic Voir le message
    ... 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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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.
    Traductions d'articles :
    La mémoire en .NET - Qu'est-ce qui va où ?
    Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
    N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.

  11. #11
    Expert confirmé
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Par défaut
    Citation Envoyé par Kropernic Voir le message
    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.
    Citation Envoyé par Kropernic Voir le message
    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.
    Citation Envoyé par Kropernic Voir le message
    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+
    "Winter is coming" (ma nouvelle page d'accueil)

  12. #12
    Membre expérimenté
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Par défaut
    Citation Envoyé par Immobilis Voir le message
    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.
    Pourquoi ajout en cascade ? La propriété s'ajoute dans la DTO concerné et c'est tout non ?
    Citation Envoyé par Immobilis Voir le message
    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.
    Effectivement, je n'ai pas parlé du constructeur. Suivant les cas, il ne faudra pas forcément le modifier.
    Citation Envoyé par Immobilis Voir le message
    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.
    Là je suis bien obligé de reconnaître que expression lambda et repository, ça ne me parle pas... P-e que, à l'instar de Mr. Jourdain, je les utilise sans savoir que ça s'appelle comme ça (mais j'en doute). Je n'ai jamais eu aucune formation .NET. Me suis auto-formé sur le tas (ça commence à faire un gros tas maintenant XD).
    Citation Envoyé par Immobilis Voir le message
    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.
    Certes, ce n'est pas grand chose mais bon... J'ai des tendances perfectionniste qui ont déjà causées quelques débats houleux avec mon collègue d'ailleurs ^^. Mais au delà de ça, pourquoi faire moins bien quand on peut faire bien ?
    Citation Envoyé par Immobilis Voir le message
    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.
    Je savais bien que j'aurais du m'abstenir de faire une comparaison (ça n'apporte jamais rien de bon ^^).
    Citation Envoyé par Immobilis Voir le message
    L'utilisation de procédures stockées et d'un ORM est effectivement la meilleure solution.
    Mon prochain projet qui ne sera pas urgent, je retournerai voir du côté d'EF. Parce que, après tout, tu avances quand même de bons arguments et qu'il est vrai que je ne travaille pas pour la NASA.

    Ca me fait penser que je suis curieux de voir comment un ORM résous des problèmes de référence circulaire. Typiquement, lorsque dans la DB on a une relation plusieurs à plusieurs entre 2 tables issues d'entité-type du MCD.
    Ex :
    Une marque peut être contenues dans plusieurs rayons et un rayon peut contenir plusieurs marques.
    J'ai donc une classe Marque et une classe Rayon. D'instinct, je suis poussé à mettre une liste de Marque dans la Rayon et une liste de Rayon dans Marque. Mais lors d'un New, c'est le bordel XD.

  13. #13
    Expert confirmé
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Par défaut
    Citation Envoyé par Kropernic Voir le message
    Pourquoi ajout en cascade ? La propriété s'ajoute dans la DTO concerné et c'est tout non ?
    Il y a aussi le parser dans lequel se trouve un champ privé.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Class DTOParser_Person
          Inherits DTOParser
     
      Private Ord_PersonGuid As Integer
    Citation Envoyé par Kropernic Voir le message
    Là je suis bien obligé de reconnaître que expression lambda et repository, ça ne me parle pas... P-e que, à l'instar de Mr. Jourdain, je les utilise sans savoir que ça s'appelle comme ça
    C'est très probable ça m'arrive souvent. Exemple de lambda:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public class Personne
    {
        public int Id { get; set; }
        public string Email { get; set; }
    }
    protected void Page_Load(object sender, EventArgs e)
    {
        IList<Personne> personnes = new List<Personne>();
        var personne1 = personnes.Where(x => x.Email == "user@domain.tld").FirstOrDefault();
        var personne2 = personnes.Where(x => x.Id == 1).FirstOrDefault();
    }
    Le Repository, pour moi, c'est juste une abstraction qui est l'équivalent de la DAL: http://msdn.microsoft.com/en-us/library/ff649690.aspx
    Citation Envoyé par Kropernic Voir le message
    Mais au delà de ça, pourquoi faire moins bien quand on peut faire bien ?
    C'est toujours un compromis.

    Citation Envoyé par Kropernic Voir le message
    comment un ORM résous des problèmes de référence circulaire
    J'aurais tendance à dire qu'il s'agit plus d'un problème de conception.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

Discussions similaires

  1. Réponses: 1
    Dernier message: 19/02/2016, 20h50
  2. Réponses: 23
    Dernier message: 08/04/2014, 17h56
  3. Réponses: 0
    Dernier message: 11/12/2013, 23h33
  4. Réponses: 0
    Dernier message: 18/11/2013, 20h49
  5. Réponses: 0
    Dernier message: 18/11/2013, 20h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo