Discussion :

[Dufok]

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 !!

[wiztricks]

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

[Dufok]

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 ! :-)

[wiztricks]

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

[Dufok]

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

[nathieb]

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