Discussion :

[LEK]

Bonjour,
j'ai lu pas mal d'article sur la manière de construire une DAL. Ainsi que sur ce site un certains nombres d'articles sur l'accès aux données.
Mais je n'arrive toujouts pas à me décider sur la meilleure méthode à prendre.
Je vais commencer un site web Asp.Net 3.5 avec oracle 10g comme base de données : quelle méthodes/outil me conseillez-vous ? quelles sont vos approches personnelles?
Les critères auxquels je suis sensibles :
- facilité de prise en main
- evolution/maintenance facile (par exemple ajout d'un champ en base,changement d'un nom/type de champ en base)
- performance
- prix (si une méthode gratuite existe je préfère l'utiliser)

Merci d'avance pour vos réponses.

[meziantou]

Il existe 2 facons de faire : à la main ou généré par un outil
Pour le deuxième cas si tu as un peu d'argent je te conseil CodeFluent Entities (qui devrait répondre à tes trois premiers critères). Cet outil est bien plus qu'un générateur de DAL comme tu peux le voir sur leur site.
Si tu n'a pas le budget il existe des ORM gratuits qui facilite beaucoup le travail : NHibernate et Entity Framework (le connecteur pour la base oracle est encore en beta)

[tomlev]

Sur quel aspect hésites-tu exactement ? Le pattern à utiliser (repository, active record...) ? La méthode d'accès aux données (SQL brut, ORM type NHibernate ou Entity Framework, génération de code type Subsonic...) ?

Selon tes critères, voilà déjà un petit comparatif entre les approches SQL brut et ORM :

• SQL brut
  
  • facilité de prise en main : bonne si tu connais déjà le langage SQL... l'API ADO.NET est assez simple à comprendre
  • evolution/maintenance facile : ça peut vite devenir horrible si l'appli est un tant soit peu complexe... (requêtes à modifier à la main un peu partout)
  • performance : potentiellement très bonne pour peu que les requêtes soient bien écrites et la base correctement indexée
  • prix : gratuit : ADO.NET est inclus dans le framework, le connecteur Oracle officiel est gratuit
• ORM
  
  • facilité de prise en main : Entity Framework est assez simple au début, NHibernate un peu moins mais ça va encore. En fait, la prise en main initiale est toujours relativement simple, mais dès que tu veux faire des choses plus compliquées ça se gate, il y a beaucoup de subtilités à prendre en compte (proxies dynamiques, lazy loading, cache...)
  • evolution/maintenance facile : c'est sans doute un des principaux avantages. L'ajout de nouveaux champs ou de nouvelles entités se fait très facilement, sans grosses modifications du code.
  • performance : bonne pour les requêtes simples (genre récupérer une entité par son ID, ou une liste d'entités selon un critère simple). Souvent assez moyenne voire mauvaise pour des requêtes plus complexes qui impliquent des jointures ou sous-requêtes... En fait ça dépend pas mal de l'ORM et du connecteur utilisés, certains génèrent des requêtes mieux optimisées que d'autres
  • prix : les ORM les plus répandus sont gratuits (en tous cas EF et NHibernate le sont). Par contre il n'y a pas de provider EF gratuit pour Oracle pour l'instant à ma connaissance (*), il faut utiliser des connecteurs payants comme celui de Devart.

Sinon, le principal avantage d'un ORM reste quand même de travailler en objet d'un bout à l'autre, sans écrire de SQL...

(*) la dernière fois que j'ai vérifié, Oracle travaillait à inclure le support d'EF dans son provider .NET, je ne sais pas trop où ils en sont... EDIT : voilà la réponse, merci meziantou

(le connecteur pour la base oracle est encore en beta)

[SoftFluent]

Rappelons simplement qu'un usage non-commercial de CodeFluent Entities est gratuit et qu'Oracle est totalement supporté par le produit.

Il est donc facile de tester l'approche ici
http://www.codefluententities.com/register_cf.aspx

Pour bien comprendre comment cela se positionne par rapport à une simple couche d'accès aux données et notamment EF, lire également ce document (en anglais) http://www.codefluententities.com/do...0Framework.pdf

CodeFluent Entities peut générer du EF, mais les scénarios sont ensuite limités par les limites actuelles de l'approche ORM.

Daniel

[LEK]

Bonsoir,
excusez-moi pour le délai de réponse... merci pour les vôtres.
En fait j'ai effectué quelque test avec nhibernate : pour les cas simples pas de problèmes en effet, mais je possède des tables avec des pk composites, un modèle relativement conséquent (200 tables) et des cas un peu particuliers à traiter (possibilité d'ouvrir des connexions au loggin sur une base différente avec les credentials personnalisés pour l'utilisateur : donc une chaine de connexion unique par utilisateur).... Et l'équipe de développement s'achemine petit à petit vers le monde objet tout en restant des développeurs juniors en la matière...
Sinon, il reste la solution purement ADO.Net (on possède effectivement une bonne connaissance du sql) mais j'ai effectivement peur de la maintenance au final avec plusieurs requêtes éparses à modifier à la main...
Je pense que je vais partir sur une solution de ce genre en utilisant MyGeneration pour automatiser le process...
Qu'en pensez-vous ? => J'ai peur qu'un outil de ce genre ne soit déjà dépassé...
Merci en tous cas pour votre patience et vos réponses assez détaillées ;-)

[tomlev]

Je pense que je vais partir sur une solution de ce genre en utilisant MyGeneration pour automatiser le process...
Qu'en pensez-vous ? => J'ai peur qu'un outil de ce genre ne soit déjà dépassé...

Je n'ai jamais utilisé ce type d'outil, mais d'après ce que j'en sais ça semble être une approche viable. Sinon il y a aussi Subsonic qui fait le même genre de choses