Discussion :

[rohstev]

Bonjour,

ce petit post pour vous demander votre avis quand à l'utilisation d'une couche d'accès aux données dans une application web.

Dans mon job j'ai déjà eu l'occasion de développer 2 applications majeure ASP.Net afin de gérer des données. Ces données sont stockées dans des bd sql server d'une certaine taille (environ 30 tables minimum dont certaines comprenant une 40aine de champs).

En lisant et relisant les "best-practices" je vois que pour développer "proprement", il faut utiliser une couche d'accès aux données. De mon côté, mes requêtes sont si complexes (nombreux croisements entre les tables) que j'ai beaucoup plus de facilité (et de rapidité) à insérer, lire ou updater des données directement dans le code behind de ma page de présentation (maPageWeb.aspx.cs).

Bien sûr mes données de connexion sont dans mon web.config et je gère mon objet Connexion du mieux que je peux.
Mais je me demandais si beaucoup de personne dans ma situation font l'effort de développer des énormes classes permettant d'accéder à la base de données sous la forme "objet".

Je sais que ce post va attirer des hurlements de certains "pros" mais mon application n'a pas pour but d'être portable sur d'autres plateforme clientes et ce qui importe avant tout c'est la rapidité de mise en prod. Côté sécurité mes appli sont utilisées dans un intranet (donc aucun accès depuis l'internet) et toutes les connexions sont identifiées par le login windows (avec gestion des logs).

Voilà, le pavé est lancé, merci de vos avis !

[mermich]

Salut,

Effectivement tu va attirer les foudres des plus fanatiques, qui vont te dire nhiber,ate, entity ou autre c'est mieux plus solide etc...

Ils n'auront pas faux, mais ce n'est pas forcément la solution la plus pragmatique.

Pour le coup je partirai plus du coté des dataset typés et d'un projet dao:
Un second projet te permet de plus fractionner ton code afin d'ètre plus lisible et les dataset typés sont suffisament productifs pour ètre utilisés (utilitaire graphique, et possibilité de mettre tout le sql que l'on veut).

un exemple: http://www.wrox.com/WileyCDA/Section...id-302833.html

En tout cas le premier point serai pour moi de centraliser tous les accès à la base de données et de stocker toutes tes requètes dans un seul endroit (projet, ou repertoire...).

T'inquètes d'autres personnes vont donner leurs avis.

[hwoarang]

Il n'y a pas de reponse tranchée, chacun fait comme il l'entend en fonction de ses connaissances/temps imparti.
C'est sur que l'ideal est de passer par un web service qui permet l'accès aux données afin de separer l'application et la base de données. Mais ce n'est pas toujours possible (ni efficace) de faire cette gymnastique.

En ce qui me concerne, je fais aussi des acces à la base de données dans mon code behind. Par contre, je regroupe tous les acces dans un seul fichier afin de mettre en commun le code redondant (recuperation de la connexion pour executer la requete, ...). Comme ca, si je dois changer, par exemple de base de données, je n'aurais qu'à me palucher les 10000 lignes de mon fichier de requete
Mais bon, de toute facon, il faudrait le faire quand meme

[jbrasselet]

Personnellement j'aime bien créer une couche d'accès aux données. Cela permet de changer assez facilement de type de base à attaquer.
Il faut bien y réfléchir et bien la concevoir.
Après je gère souvent la connexion entre ma couche présentation et ma couche d'accès aux données par des DTO, ce qui facilite les choses (mais demande un effort de code un peu plus important je l'admets)

C'est une pratique que je m'impose souvent mais cela dépend bien entendu de la taille du projet et des différentes contraintes.

[Nathanael Marchand]

Effectivement, je bondis à la lecture de certains propos! Mais pas que ceux de rohstev!
Deja y'a deux notions qu'il ne faut pas mélanger: DAO et ORM... C'est pas parce qu'il y'a une couche d'accès aux données qu'il y'a un ORM (type NHibernate ou Entity Framework) derrière. Ca peut très bien être de l'ADO.Net ca marche impec...
Ensuite concernant la couche DAO:
-Déjà ne pas se cacher derrière "la complexité" d'une base, y'a toujours plus complexe ailleurs (sans vouloir jouer à qui a la plus grosse, je bosse sur +100 tables et quelques téras sans avoir la plus grosse base de la où je suis)
-Second truc: ton chef te dit "la volumétrie commence à etre grosse, les perfs sont pourries, on va mettre un cache devant la base de données", tu te vois modifier tous tes GUI pour ca? (Meme chose si passage SQL Server vers Oracle ou même fichier XML)
-Troisième point: toi qui a l'air de t'interesser aux mises en prod. Plutôt que de t'interesser au temps de mise en prod, ne vaudrait il pas mieux s'assurer de la qualité de celle-ci? Comment gères tu tes recettes? Tes tests unitaires?
Quand t'as une grosse bouillie (un code spaghetti on appelle ca), c'est impossible il faut tester toute la chaine. Un changement sur l'accès aux données peut tout te casser dans des coins que tu maitrises pas. Un cloisement bien défini permet d'éviter ceci.
-Quatrième point: la factorisation du code! Si dans deux pages différentes tu dois afficher la meme chose: deux fois la meme requete, deux fois plus de temps perdu, deux fois plus de sources d'erreur.
-Cinquième point: tu n'es pas eternel (même si je ne te souhaite aucun mal évidemment), tu ne resteras pas eternellement à maintenir ces applis. Pense au développeur suivant qui passe et qui sur une seule classe doit réussir à démeler le code métier, le code données et le code de présentation.
-Sixième point: l'inverse du deux. "On vient de racheter une filliale à HongKong, bien sur ils sont pas sur le même active directory, on veut donc migrer de Winform à Webform (ou silverlight, ou autre)" bon ben t'as plus qu'a tout jeter et tout refaire.

Pour moi, la seule raison pragmatique de ne pas faire de couches est moi d'être sur que l'appli est une maquette et que dans un mois on la jette(et même dans ce cas la, y'a pas grand interet à faire une base de données derrière)!
C'est comme un Stop dans le code de la route, bien souvent on s'arrête alors que y'a personne alors c'est tentant de le griller, jusqu'au jour ou...
Par experience, on a bien souvent vu en entreprise (et ca va de la startup jusqu'a la plus grande banque de finance au monde) des grosses bouses qu'un clampin a développé(je parle pas de toi hein) dans son coin à l'arrache en se disant que de toute facon y'a que lui qui s'en servira et qui ont pris une place très importante!
Exemple: une grande banque. Les équipes de recherche ont développé un pricer des instruments financier "oué mais vous comprenez c'est un truc rien que pour nous, on a des besoins spéciaux". Sauf que y'a un chef qui passe par là et qui se dit "ah le truc la il fait un truc que nous on a pas et donc on le veut aussi". Au fur et à mesure, ca se propage dans la banque. Comme ca devient un truc assez gros, il transfèrent ca de l'équipe de la recherche vers une vrai équipe de dév. Sauf que, vu que ca devait servir qu'à la recherche, ils avaient pas prévu de couche de sécurité. Lorsque les inspecteurs de la sécurité ont vu ca ils sont devenus vous, les équipes de dév ont pleuré pour implémenter ca (bah oui, rajouter une couche sensible & transverse sur une appli bancale, c'est dur).

Voila pour mon explication! Conclusion: toujours utiliser des couches! Ca coûte pas beaucoup plus cher (en plus c'est vrai) et ca un ROI tellement elevé! (Et pardon si j'ai été un peu trop véhément)