février
2010
Un article de Philippe Vialatte
.c’est quand on doit s’en passer après une longue période d’utilisation !
Tout le mois de Décembre (et une bonne partie de Janvier), j’ai travaillé quasi-exclusivement sur un projet ou la DAL était générée avec des templates tt customisés de Subsonic 3.
Tout allait bien, la vie était belle, faire une nouvelle requête me prenait grosso modo 5 minutes, dans le genre :
1: DataRepository<Customer>.GetAll()
2: .Where(customer => customer.fk_company == companyId)
Et tout ca avec possibilité d’injecter le Repository que je voulais en cas de test, et la certitude que je ne récupérerais que les données que je veux, sans me poser plus de questions (oui, dés que j’ai du temps, j’en dis plus, promis.).
Et la, du jour au lendemain, je reprends un projet qui suit le format « classique » des DAL basées sur des procédures stockées, avec une procédure stockée appelée par la couche DataAccess, elle-même appelée pa la couche Business, elle-même appelée par la couche Web.trois classes pour un appel à la base, avec, au final, moins de découplage et le même niveau de performances.
Je ne l’ai pas beaucoup exprimé auparavant, et c’est un avis à moi que j’ai, mais utiliser des procédures stockées pour faire des opérations CRUD est, pour moi, devenu un anti-pattern.
Les remarques habituelles de performances sont valables pour des procédures stockées complexes, mais, sur un projet ou 80% des procédures stockées sont des opérations mono-tables, elles n’ajoutent, à mon avis, qu’une surcharge cognitive à l’application (ou est le bug ? dans la table, la procedure, la couche DAL, la couche Business, la couche Web, le framework ???)
Pour tous les prochains projets, la cible que je vais essayer d’atteindre, c’est du 95% de code ORM, et 5% de Procédures stockées pour les traitements lourds.
Et vous (enfin, toi, mon unique lecteur :D), qu’en pensez-vous ? Utilisez-vous encore des procédures stockées ? Sont-elles un mal nécessaire, une aberration antédiluvienne, ou la seule raison pour laquelle vous vous levez le matin ?
6 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
c’est marrant, il m’est arrivé exactement l’inverse. J’ai bossé 6 mois sur une archi 3 couches + wcf et des procédures stockées avant de pouvoir enfin jouer un peu qvec subsonic (peut-être un article à venir en collaboration avec Philippe qui sait).
Sur le papier, l’archi 3 tiers paraît plus simple à expliquer à nos amis indiens qui bossent avec nous en distribué.
En réalité…non
>ajouter éventuellement un projet supplémentaire de DAL
Une note, juste parce que j’avais trouve ca marrant quand je suis arrive dans la boite, et que maintenant ca me fait pleurer, notre tronc principal a 118 projets. Quand il y a besoin d’ajouter un nouveau projet, ca me fait entrer en depression.
>je pensais que CodeSmith générait aussi la partie DAL
Disons que la version de CodeSmith qu’on utilise est un peu (beaucoup) datee; on se contente de generer les CRUD avec. Toute la gestion de cache, de la persistance, du mapping, les transactions, le lazy loading… tout ca c’est pour nous.
>de migrer progressivement tout le code vers la nouvelle DAL
Je suis d’accord et c’est ce qu’on fait; enfin disons que la premiere etape est d’utiliser L2S pour des projets internes. Rien de transcendant mais c’est une premiere etape.
>je te conseillerais plutot d’investir dans NH
Le probleme avec NH c’est que ce n’est pas MS et que la documentation est plus spartiate. C’est idiot mais les commentaires sur le blog d’Ayende, notamment Frans Bouma, ont mis le doigt dessus. Je prefererai aussi NH pour sa flexibilite et sa maturite mais c’est plus difficile a vendre.
Quand a EUSS, c’est plus une elucubration de ma part en tant qu’ancien utilisateur de DTM (un L2S 7 ans avant :)); aucune chance qu’il soit choisi.
> C’est lisible, beaucoup plus que le SQL dans le code
Justement, ca l’est, à mon avis, de moins en moins avec l’arrivée d’outils de mapping un peu évolués. C’est sur qu’entre une chaine sql construite à la main à l’arrache dans la code de la page web/formulaire et un appel propre à une SP, il y’à un monde, mais, même si les entlib ont permis de diminuer la friction, il reste laborieux d’utiliser les SP (pas d’intellisense, pas de contrôle sur le contenu de la SP depuis VS, logique métier cachée dans les SP…) par rapport à un ORM.
> toute la DAL est a la mano, on est dans le cambouis et on perd un temps fabuleux la dedans
Tiens, je pensais que CodeSmith générait aussi la partie DAL.
> On essaye de passer a un ORM, EF ou NH ou EUSS ou n’importe quoi d’autre
> mais on ne change pas 6 ans de code et 12M de LoC du jour au lendemain.
Ca me rappelle quelque chose ;)…bon courage
Bon, plus sérieusement, c’est à la limite de l’impossible de changer tout (façon big bang), surtout si c’est un unique produit, par contre, ca doit être jouable de « vendre » le développement des nouvelles fonctionnalités en partant sur un ORM (ajouter éventuellement un projet supplémentaire de DAL), et de migrer progressivement tout le code vers la nouvelle DAL.
Sinon, comme tu mentionnes EF/NH/EUSS, pour le moment, je te conseillerais plutot d’investir dans NH, dans ces trois la (EUSS est trés peu actif, donc attention au support, et EF « bouge » encore beaucoup).
On utilise dans ma boite les procedures stockees et j’y vois les avantages suivant:
-Je peux utiliser SQL prompt pour ecrire mes SP; c’est un peu le Resharper de SSMS
-C’est lisible, beaucoup plus que le SQL dans le code
-La correction de bug se fait plus facilement et rapidement en production
-C’est plus facilement maintenable
Le cote negatif:
-Le gros atout de pouvoir corriger les bugs dans les SP fait que souvent, la logique metier fait son apparition dans les SP. J’ai meme vu dans notre code des messages de validation retournes par les SP. Beurk!
-La maintenance (je sais c’est aussi un point positif) est un enfer , ca devient ingerable: on a actuellement 1329 SP dans le systeme et aucun historique; la seule chose sous source control sont les fichiers sql. le debug est laborieux (aussi parce que la logique metier fait son apparition dans les SP)
-Ecrire du SQL c’est quand meme chiant, mais ca c’est tout a fait personnel
On utilise CodeSmith pour la generation des CRUD mais on se tape un paquet de SP a la main; toute la DAL est a la mano, on est dans le cambouis et on perd un temps fabuleux la dedans. Et pendant qu’on ecrit toutes les procedures d’acces aux donnees, les ajouts de fonctionnalites ne se font pas.
On essaye de passer a un ORM, EF ou NH ou EUSS ou n’importe quoi d’autre mais on ne change pas 6 ans de code et 12M de LoC du jour au lendemain.
+1
Bonjour,
Moi aussi je pense que les procédures stockées c’est bon pour les traitements lourd.
Je n’utilise pas encore linq ni les templates (codesmith, subsonic ou autres) j’en suis encore à tout faire à la mano (mais j’ai peu de tables)
– couche métier qui mappe ma base
– couche service qui renvoi souvent des objets métiers après avoir appelé la couche data
– couche data qui utilise le Microsoft Data Access Block pour taper dans la base et qui tape aussi dans une couche « common » ou son stocker les nom des champs dans la base, les noms des parametres et les requetes pour chaque table/objet métiers.
A l’ancienne quoi.
Salutations