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

Autres Discussion :

Soucis avec mon futur DAO


Sujet :

Autres

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    février 2005
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 13
    Points : 10
    Points
    10
    Par défaut Soucis avec mon futur DAO
    Bonjour,

    J’ai un soucis avec l’architecture multi-couches que je suis en train de mettre en place. Le contexte est le suivant :

    - Un site web vieillissant tourne sur une base Oracle. Cette base de données est volumineuse.
    - Il a été choisi de réécrire ce site web en asp.net
    - En plus de ce site web, nous devons écrire un logiciel pocket avec une base embarquée SQLite, sous Windows mobile 6.5 et inférieurs (le logiciel tournera sur des Psion).

    La partie métier et service sera donc commune aux 2 plateformes.
    Cependant, j’ai un problèmes avec ma couche DAO. Je me vois mal écrire 2 couches différentes qui seront composées à peu de choses près du même code (à part pour les dates, la syntaxe SQL entre Oracle et SQLite est proche) : une pour Oracle, une pour SQLite. Ca doublerait les coûts de maintenance en cas d’erreur dans une des requêtes exécutées.
    Je ne vois que 2 solutions pour respecter la structure d’une architecture multicouches :

    1. Ecrire entièrement le DAO à l’aide d’un framework de persistance… Les requêtes seront ainsi identiques sous Oracle comme sous SQLite. Cependant, personne dans la société ne maîtrise encore correctement ces outils, et j’ai vraiment peur des performances au moment où les métiers tourneront sous Oracle en production (la base est vraiment grosse, et les requêtes peuvent être assez compliquées )

    2. Ecrire un « Wrapper » de base de données. En gros, il n’y aura qu’un DAO (et non pas un pour Oracle, un pour SQLite), qui utilisera ce Wrapper pour interroger la base de données. Donc, par exemple, si le DAO tourne sur SQLite, lors d’une interrogation il récupérera un DbDataReader, pendant que le Wrapper travaillera lui avec un SQLiteDbDatareader. De plus, si besoin, il transformerait le SQL pour l’adapter aux spécificités de la base sur laquelle il tourne.

    3. … ? D’autres solutions ?


    Et vous, comment verriez-vous les choses ?


    Merci !!

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    17 563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 17 563
    Points : 30 304
    Points
    30 304
    Par défaut
    Salut,
    Il faut voir plus bas dans les incompatibilités des types de données mais normalement un ORM (genre nhibernate) devrait pouvoir réaliser ce genre d'abstraction.
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    février 2005
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 13
    Points : 10
    Points
    10
    Par défaut
    Merci pour la réponse ! Donc tu opterais pour la solution n°1

    Mais pour une grosse base de données, les performances de nHibernate seront-elles suffisantes ? Ne risque-t-on pas de perdre du temps à le paramétrer correctement ?

    Autre question : si j'utilise ce genre de framework pour faire mon DAO, ma couche objets métiers aurait-elle le droit d'écrire directement des requêtes d'interrogation dans le langage du framework ?

    Merci ! :-)

  4. #4
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    17 563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 17 563
    Points : 30 304
    Points
    30 304
    Par défaut
    Citation Envoyé par Dufok Voir le message
    Mais pour une grosse base de données, les performances de nHibernate seront-elles suffisantes ? Ne risque-t-on pas de perdre du temps à le paramétrer correctement ?
    J'ai suggéré NHIBERNATE car .NET, mais il existe certainement d'autres solutions côté ORM. Côté performances, il est clair qu'ajouter des couches ne va pas aider. Mais ce n'est pas 'horrible'.

    Oui, vous passerez du temps à le paramètrer "correctement" et à vous approprier "comment le mettre en oeuvre proprement" et à vous former à... à défaut de trouver les compétences qui savent.

    Dans tous les cas, l'application travaillera avec des "objets" dont certains seront "persistés". D'après ce que j'ai compris, comme vous héritez d'un modèle de données, tout dépendra de "l'écart" entre le modèle de données applicatif, les schémas existants et les opérations que vous allez faire dessus.

    L'ORM permet de combler l'écart via un mapping sophistiqué des objets et de la persistance. Une solution "plus classique" est d'aligner côté BDD en passant par des Views et des procédures stockées.

    Note: Côté performances, ce faisant on rapproche données et traitements et c'est généralement "mieux" côté performances... Mais c'est une autre façon de ... et çà demande aussi des compétences.

    Autre question : si j'utilise ce genre de framework pour faire mon DAO, ma couche objets métiers aurait-elle le droit d'écrire directement des requêtes d'interrogation dans le langage du framework ?
    Normalement oui. Reste à voir les possibilités du framework par rapport à vos attentes.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    février 2005
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2005
    Messages : 13
    Points : 10
    Points
    10
    Par défaut
    Ok, merci pour ces infos :-)

    Par contre n'est-ce pas un peu "contre nature" de permettre à la couche métier de pouvoir elle-même écrire des requêtes ? Car dès lors cette couche métier devient dépendante de la technologie utilisée pour le DAO... Bien que, normalement, cela ne devrait jamais arriver.

    En plus, si on fait ça, on va se retrouver avec des requêtes du framework de persistance dans le DAO et dans la couche métier

  6. #6
    Membre expérimenté Avatar de nathieb
    Homme Profil pro
    DevOps
    Inscrit en
    mai 2004
    Messages
    1 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : DevOps
    Secteur : Service public

    Informations forums :
    Inscription : mai 2004
    Messages : 1 055
    Points : 1 523
    Points
    1 523
    Par défaut Architecture
    Bonjour,

    Dans le cadre d'indépendance d'accès aux bases de données, il ne faut pas réinventer la roue hibernate est une bonne alternative, cependant il faudra prendre en compte la montée en compétence de l'équipe.
    Mais hibernate a comme tout ORM des limitations
    attention aux objets ésoteriques genre ORDIMAGE pour Oracle.

    sinon chaque ORM permet de pervertir l'ORM en injectant des requêtes
    en SQL natif, je connais hibernate sous java.

    Souvent je fais deux couchesen java j'utilise une couche qui mappe les tables
    JPA en java le fait très bien, je mappe les colonnes et les get/set hibernate le fait de façon presque automatique.
    Ainsi une couche service utilise cette dernière le "DAO" en somme, les vrais objets métiers, la matière grise ...

    Je peux donc avoir un couplage faible entre les deux.

    Souvent sous les ORM, il faut activer les logs SQL, on voit ainsi voir la trace des requêtes, et donc optimiser.

    Olivier
    Architecte destructurant,
    be cool, be free

    Il nous reste Debian bien sûr

Discussions similaires

  1. soucis avec mon script de news
    Par Ludo75 dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 11/01/2007, 14h41
  2. soucis avec mon applet et JMenuBar
    Par nazimb dans le forum AWT/Swing
    Réponses: 6
    Dernier message: 08/07/2006, 09h35
  3. [Conception] soucis avec mon code de recherche par un ou plusieurs critères
    Par jolipepage75 dans le forum PHP & Base de données
    Réponses: 18
    Dernier message: 11/06/2006, 02h59
  4. Souci avec mon recordcount......
    Par WyLLoU dans le forum Access
    Réponses: 14
    Dernier message: 03/02/2006, 11h59
  5. petit soucis avec mon graveur
    Par Vador dans le forum Périphériques
    Réponses: 8
    Dernier message: 02/11/2005, 14h58

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