Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Vins' blog

Blog technique de Vincent Bellet sur le monde Microsoft : actualités, Imagine Cup, .NET...
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 :
Posted: jeudi 17 mai 2007 13:10 par ElVins

Commentaires

ROMELARD Fabrice a dit :

Cette question a déjà été évoquée à plusieurs reprises.

Il y a des cas oû l'utilisation de ce mode (SQL dans ASPX) est impensable (ce qui semble être votre cas) :

- Grosse application

- Séparation des équipes de développement

- Respect des couches de développement

- ...

Mais dans certains cas, on peut privilégier ce type de choix comme :

- Application jetable (utlisé d'une fois)

- Partie administrative de l'application (couvent peu de temps alloué pour la réaliser)

- Apprentissage (pour des développeurs venant du développement PHP ou ASP notamment)

- ...

Tout n'est donc pas si figé qu'on peut le penser, on peut donc avoir besoin de voir rapidement le contenu d'une table ou d'une liste d'objet dans la partie admistrative d'une grosse application (qui peut être sur un autre serveur ou site web interne), il est donc plus simple de passer par la.

Fabrice

# mai 17, 2007 15:24

patrice a dit :

Même avis que fabrice...

Cela peut également servir pour faire du maquettage ou également pour les développeurs Access qui souhaitent faire du web. Avoir ce genre de DSO permet de facilement passer à .net...

# mai 17, 2007 16:17

cyril a dit :

Le SqlDataSource est adapté pour les tout petits sites, site perso, site de démo, site de test, à la rigueur back office pour les données non stocké dans la couche données.

Mais sinon pour des grosses applications, c'est beaucoup plus propre est maintenable d'avoir toutes les requetes SQL (comprendre requete ou procèdure stocké) dans une seul couche.

L'objectDataSource est par contre un peu plus utilisable, meme si je doute qu'il soit souvent utilisé dans de gros projets ...

De toute facon ce problème sera en partie résolue "grace" à Linq to sql ainsi que linq to entities.

# mai 17, 2007 17:46

romagny13 a dit :

Moi ce qui me sidere c'est que d'un côté Microsoft dit "on va bien séparer les couches" ainsi les graphistes pourront travailler d'un coté et les developpeurs de l'autre patati patata et de l'autre côté ils font l'inverse de ce qu'ilsz disent > binding en wpf et en asp.net les controls qui sont certaineemnt trés pratiques (formview,detailview) mais pour lequel on est obligé de passer par le code de la couche présentation(ds le xaml ou le asp) pour definir la source de données de ces controls et il est trés difficile voir impossible defaire autrement et ca franchement ca m'inquiete et me pose pb

# mai 17, 2007 20:49

Kangoo a dit :

Tu veux de la séparation par couche ?

Jette donc un oeil à Web Service Software Factory de l'équipe Pattern & Practice... C'est ce qu'on utilise actuellement avec mon équipe et c'est génial : ça exploite bien le G.A.T pour Visual Studio et ça rentre dans une belle démarche d'industrialisation.

++

# mai 17, 2007 21:43

NeuroCypher a dit :

Dans la boite ou je bosse en ce moment, toutes les requetes utiles a l'ASPX sont faitent en procedures stockees, ce qui pallie a ce probleme...

Par contre, niveau application windows, la tu peux t'arranger pour que ce ne soit pas dans la meme couche donc le probleme n'est pas consequant je pense.

Sinan je suis assez d'accord avec ce qu'a dit fabrice aussi sur le principe.

# mai 17, 2007 23:28

ElVins a dit :

Bon ca rejoint ce que je pensais, merci pour vos reponses actives et constructives les gars.

Kangoo tu m en as deja paerle et j ai pas eu le temps de regarder mais ca devient necessaire, merci de m avoir rappele le nom!

# mai 18, 2007 09:50
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01