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

Accès aux données Discussion :

Best practice Data Access Layer


Sujet :

Accès aux données

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé Avatar de touftouf57
    Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 362
    Par défaut Best practice Data Access Layer
    Bonjour à tous.

    Je peine à créer mon Modèle dans une architecture MVP.

    Voici l'architecture des objets

    Règle
    --Colonne [1-n]
    --VersionColonne [1-n]
    --Cellule [1-n]

    Je m’arrête à ce niveau car l'arborescence est longue.

    J'ai créé un Modèle RegleModele qui contient la règle courante ainsi qu'un DAORègle qui me permet de faire les opérations CRUD de cette règle.

    L'utilisateur peut modifier tous les items de l'arborescence, mais il ne peut faire effectuer que la sauvegarde de la règle.

    A savoir:
    • les données ne sont pas toutes sur la même base de données.
    • C'est une application multi utilisateur, il me faut donc pouvoir gérer les accès concurrentiels.


    Pour les accès concurrentiels, j'ai choisi d'utiliser les dataset, puisque les datatables sont capables de gérer ce problème.

    Mais comment concevoir mon modèle correctement, puisqu'il me faut une requête SELECT pour que le CommandBuilder puisse créer les requete UPDATE et DELETE de chaque item.


    Donc, mon modèle RègleModèle doit il contenir toutes les DAO (DaoColonne, DaoVersionColonne,...)? Solution que je ne trouve pas très "propre".
    Ou bien contient-il d'autres modèles (ColonneModèle, VersionColonneModèle,...)? Mais là aussi je ne trouve pas cela très propre, ni simple à coder et à maintenir.

    Merci de vos conseils. A moins que quelqu'un ai l'adresse d'un bon tutoriel parce que j'ai beau cherché je n'ai pas trouvé grand chose qui m'éclaircisse les idées.

  2. #2
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par touftouf57 Voir le message
    Pour les accès concurrentiels, j'ai choisi d'utiliser les dataset, puisque les datatables sont capables de gérer ce problème.
    Les DataSets, c'est un peu la 2CV du .NET... C'est dépassé quoi :
    - C'est verbeux
    - Pas très souple
    - L'utilisation est assez lourde, en terme de conso ressources
    - Les données ne sont pas fortement typées

    Bref, rien de tel que des listes d'objets.

    Citation Envoyé par touftouf57 Voir le message
    Mais comment concevoir mon modèle correctement, puisqu'il me faut une requête SELECT pour que le CommandBuilder puisse créer les requete UPDATE et DELETE de chaque item.

    Donc, mon modèle RègleModèle doit il contenir toutes les DAO (DaoColonne, DaoVersionColonne,...)? Solution que je ne trouve pas très "propre".
    Ou bien contient-il d'autres modèles (ColonneModèle, VersionColonneModèle,...)? Mais là aussi je ne trouve pas cela très propre, ni simple à coder et à maintenir.
    Pourquoi emploies-tu le terme "contenir" ? Tu dois juste avoir des liens entre tes différents modèles, autrement dit ton RegleModele doit utiliser une instance (ou plusieurs selon le cas) de tes autres modèles.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  3. #3
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par DotNetMatt Voir le message
    - Les données ne sont pas fortement typées
    Les DataSet typés ça existe.

  4. #4
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par h2s84 Voir le message
    Les DataSet typés ça existe.
    Ouais mais bon ça reste quand même un dataset...
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  5. #5
    Invité
    Invité(e)
    Par défaut
    @DotNetMatt,
    Citation Envoyé par DotNetMatt Voir le message
    Ouais mais bon ça reste quand même un dataset...
    Ce n'est pas uniquement un DataSet mais un DataSet typé et les données sont fortement typées donc ce que tu dis ci-dessous est faux.
    Citation Envoyé par DotNetMatt Voir le message
    - Les données ne sont pas fortement typées
    @touftouf57,
    La solution proposée par Meziantou est très bien. Pas mal d'ORM utilise cette solution.

  6. #6
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par h2s84 Voir le message
    Ce n'est pas uniquement un DataSet mais un DataSet typé et les données sont fortement typées donc ce que tu dis ci-dessous est faux.
    Oui ça j'ai bien compris et on est d'accord sur ce point.

    Mais ça ne change rien au fait que ça reste un DataSet, et que c'est vieillot et lourd ! Je trouve ça dommage d'orienter un débutant sur l'utilisation des DataSets.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  7. #7
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par DotNetMatt Voir le message
    ge rien au fait que ça reste un DataSet, et que c'est vieillot et lourd !
    Arrête de t'emballer pour un DataSet typé.

    Citation Envoyé par DotNetMatt Voir le message
    Je trouve ça dommage d'orienter un débutant sur l'utilisation des DataSets.
    Qui est-ce qui a dit, recommandé, conseillé un DataSet (typé ou non) à ce "débutant" dont tu parles ? Ce n'est pas moi. Le message (je dis juste que les données d'un DataSet peuvent être fortément typées pour contredire ton propos) où j'ai notifié l'existence d'un DataSet typé et ma recommandation sont bien distinctes. Ma recommandation, quand à elle, ne porte pas sur un DataSet (typé ou non). D'ailleurs dans mon précédent message je recommande la solution de Meziantou.

  8. #8
    Membre émérite
    Homme Profil pro
    Inscrit en
    Février 2006
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations forums :
    Inscription : Février 2006
    Messages : 564
    Par défaut
    Citation Envoyé par DotNetMatt
    Les DataSets, c'est un peu la 2CV du .NET... C'est dépassé quoi :
    - C'est verbeux
    - Pas très souple
    - L'utilisation est assez lourde, en terme de conso ressources
    - Les données ne sont pas fortement typées
    Désolé de te contredire mais je ne suis pas du tout d'accord avec toi. Les DataSets peuvent être fortement typés et font partis intégrante d'ADO.Net. C'est très simple à mettre en place et à manipuler, très rapide mais manque de fonctionnalités.

  9. #9
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Billets dans le blog
    3
    Par défaut
    Oui h2s84 m'a déjà fait remarqué que ça existait...

    Bref il n'en reste pas moins le Dataset c'est ce qui existait avant l'apparition des generics dans le .NET 2.0, quand on n'avait pas d'autre choix pour manipuler les données parce que c'était plus complexe de travailler avec les collections.

    Oui il y a plus de code à écrire quand on crée des objets custom, mais au final c'est beaucoup plus clair et compréhensible. Chaque classe est taillée sur mesure pour son domaine. On peut l'étendre et réaliser la maintenance plus facilement puisque c'est clairement découpé (chaque classe ayant un rôle bien précis). Alors bien sûr, sur le coup, ça demande plus de boulot donc à court terme c'est consommateur de budget. Mais à moyen/long terme, on y gagne, les coûts de maintenance/évolution étant réduits.

    Quand on part avec un DataSet sur une application d'entreprise relativement complexe, c'est sûr qu'au début tout est facile. Puis viens la mise en prod, puis le début de la maintenance et là bonjour la pagaille ! Sur le coup, on ne va rien consommer en terme de budget, mais à moyen/long terme, les coûts vont exploser. C'est l'erreur que commettent de nombreux chefs de projet.

    Pour conclure, et je m'arrêterai là, j'assimile le DataSet à un panier : on y met tout et n'importe quoi (des choux, des oeufs, du lapin, des stylos...), sans trop se poser de questions, puisqu'il est polymorphique... Rien n'est donc clairement découpé, la doc sera probablement succinte (ah oui, à quoi bon en faire une, puisque tout est dedans ?)

    Donc les DataSets, c'est bien pour des applications simples, ou alors pour prototyper, ou encore si on a une deadline très très courte et qu'on n'a pas le choix. C'est surtout pour du court terme... Pour une application très simple effectivement, ajouter des objets custom peut rajouter de la complexité inutilement, mais pour une application avec un minimum de complexité, il vaut mieux consacrer du temps à créer ses objets custom, et surtout bien réfléchir aux impacts budgétaires.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  10. #10
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par touftouf57 Voir le message
    • les données ne sont pas toutes sur la même base de données.
    • C'est une application multi utilisateur, il me faut donc pouvoir gérer les accès concurrentiels.
    Rien ne t'empêche d'avoir une couche DAL pour chaque base de données.
    Si chaque base de données est hébergée par un SGBDR digne de ce nom alors l'accès concurrentiel ne devrait pas être un problème. Sinon les ORM tels que NHibernate, Entity Framework et les outils comme CodeFluent Entities te permettent de gérer l'accès concurrentiels.

  11. #11
    Membre éclairé Avatar de touftouf57
    Profil pro
    Développeur .NET
    Inscrit en
    Décembre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 362
    Par défaut
    Si chaque base de données est hébergée par un SGBDR digne de ce nom alors l'accès concurrentiel ne devrait pas être un problème.
    C'est bien le problème. Si je fais

    UPDATE Regle SET nomRegle="newNom" WHERE idRegle = 124

    Et bien il n'y aura aucun accès concurrentiel et ce même si la règle 124 a été modifié depuis Ma lecture.

    les ORM tels que NHibernate, Entity Framework et les outils comme CodeFluent Entities te permettent de gérer l'accès concurrentiels
    L'entreprise dans laquelle je bosse est plutôt frileuse envers ces "nouvelles" technologies.

    autrement dit ton RegleModele doit utiliser une instance (ou plusieurs selon le cas) de tes autres modèles.
    C'est la solution vers laquelle je pensais me tourner. En revanche, cela ne sera pas des Modèles mais des DAO.

    Pourquoi emploies-tu le terme "contenir"
    Quand je dis contenir cela signifie: "Avoir une référence sur une instance de la classe XX". Je sais que ce n'est pas correct sémantiquement parlant, mais c'est plus court.

  12. #12
    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
    Citation Envoyé par touftouf57 Voir le message
    C'est bien le problème. Si je fais

    UPDATE Regle SET nomRegle="newNom" WHERE idRegle = 124

    Et bien il n'y aura aucun accès concurrentiel et ce même si la règle 124 a été modifié depuis Ma lecture.
    Pour faire de la concurrence optimiste il faut ajouter une colonne de type rowversion ou timestamp
    http://technet.microsoft.com/fr-fr/l.../ms182776.aspx

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
        UPDATE maTable SET ...
        WHERE Id = @Id AND _rowVersion = @_rowVersion

    Citation Envoyé par touftouf57 Voir le message
    L'entreprise dans laquelle je bosse est plutôt frileuse envers ces "nouvelles" technologies.
    Ca peut valoir le coup de faire une petite étude sur chacun des produits pour voir ce que ca peut apporter (surtout le dernier )

Discussions similaires

  1. Réponses: 1
    Dernier message: 28/10/2009, 14h08
  2. [DC] Architecture Data Access Layer
    Par GoldenToad dans le forum Diagrammes de Classes
    Réponses: 3
    Dernier message: 25/02/2008, 08h44
  3. Data access layer (DAL) en DotNet
    Par Wurlitzer dans le forum Oracle
    Réponses: 1
    Dernier message: 18/08/2006, 01h17
  4. [Data Access Object]Intérêt de la factory ?
    Par le Daoud dans le forum Général Java
    Réponses: 2
    Dernier message: 21/04/2005, 09h06

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