La separation des couches : mythe ou realite?
Salut a tous,
Je vais m attaquer un sujet qui leve souvent des debats et polemiques et votre avis m interesse.
Je prepare actuellement mon MCTS ASP.NET par les learning officiels MS. Une chose m a frappe hier pendant l unit consacree a l affichage des donnees via les controls ASP.NET (datagrid, gridview...).
En effet, un des benefices non negligeables de .NET 2.0 est nul doute son IDE officiel. Un des avantages est de pouvoir developper des choses tres rapidement, qui demanderaient a la main surement plus de temps....bref! Ce qui me "sidere" c est l utilisant des objets source. Bien que tres bien faits, ils vont a l encontre de la separation des couches, notamment de pattern comme MVC.
En particulier dans une appli web, il est vraiment important de pouvoir separer la logique metier, de la presentation, des donnees. Je concois que pour des applications simples cela s avere peut etre non pertinent.
Personnellement, je suis en charge de mettre en place des solutions techniques dans le monde Microsoft (.NET/SQL Server et Sharepoint) pour l equipe de Londres de la banque d investissement societe generale, je peux vous garantir qu il est impensable d utiliser des requetes SQL dans la couche presentation. Quand je vois des requetes inside les fichiers aspx, j hallucine un peu. Merci le dynamisme si vous modifiez ne serait ce que le nom d une table, vous etes bons pour modifier votre code et le redeployer sur les serveurs de prod (process long et delicat dans de grandes organisations). Le raisonnement va plus loin, pour des raisons de securite (a moins de faire un deploiement readonly ou le contenu des fichiers aspx se trouve compile dans une DLL) sinon on peut acceder au contenu de la requete.
Je suis meme de plus en plus contre l utilisation de requetes SQL inside l application. Pour la simple et bonne raison qu il faut recompiler l appli ou du moins votre couche de donnees selon votre architecture des que vous changez quelque chose. Dans la plupart de nos choix techniques, la solution des procedures stockees avec SQL Server 2005 est privilegiee (je sais qu il y a des avantages/inconvenients pour les requetes comme pour les proc stockees)
Je serais curieux d avoir vos avis constructifs sur cette question.
Vincent
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
