"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Critique de l’architecture ASP.NET

Posted by patrick sur mars 13, 2007

J’ai mis en évidence quelques points d’une étude réalisée par Guillaume Saint-Etienne (document original: http://docs.google.com/View?docid=dhp3ggmx_24p2k9h7)

Le document modifié: http://docs.google.com/Doc?id=dcc3chdz_3fbp8z6

ASP.Net fait-il du Model View Controler (nativement)?

La réponse est définitivement NON

http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx

Même si Microsoft a tenté d’affirmer le contraire pour céder à la mode des MVC et montrer que ASP.Net est super bien foutu.

Le problème avec ASP. Net est qu’il n’y a qu’un objet qui traite les demandes http, c’est l’objet PAGE.

C’est lui qui a le contrôle de tout, et donc il mélange le code dit de «contrôle», et le code qui pilote la «visualisation» des éléments en html.

Et bien souvent, on mélange aussi le code qui pilote le «Modèle» c’est à dire l’obtention des données directement depuis la base de données avec Ado.Net (c’est ce qu’on obtient lorsqu’on fait du WYSIWYG dans Visual Studio en choisissant les Sql Data Source et les glissant-déposant sur l’ihm).

Cet anti-modèle (ou anti–pattern) a été souvent pointé du doigt par les architectes et développeurs, car en plus de faire produire du code spaghetti (bien que orienté objet), il rend impossible les tests systématisés (automatisés).

Egalement, les bugs sont plus durs à corriger et plus nombreux, car on n’isole pas assez les responsabilités dans les lignes de code. Tout est mélangé dans le code-behind.

Et au final, on peut se demander si l’on a fait beaucoup de progrès depuis Asp ( sans .Net) ?

Bref, le modèle MVC apporte de réelles améliorations et il est préférable de le suivre dès lors qu’on écrit un site de plus d’une dizaine de pages et surtout un site où on aura beaucoup de feedback de la part des utilisateurs et beaucoup d’améliorations successives à apporter.

Autant dire que c’est indispensable quand on a un projet à la méthode Agile (type MSF, Scrum, Xtreme Programing …).

Il faut donc, pour faire du MVC avec ASP.Net écrire du code supplémentaire soi-même, ce qui n’est pas un travail négligeable.

Ou bien si l’on est un peu plus malin, utiliser un Framework qui le fait à notre place.

C’est le rôle du projet Monorail : http://www.castleproject.org/monorail/index.html

L’idée est de se dire : MVC c’est bien. Je veux en faire (pour tous les avantages cités, notamment la ‘testabilité’). Mais je veux choisir quel système va s’occuper de la Vue (c’est à dire le RENDU au format HTML ou un autre format similaire, tant qu’à faire).

En ASP.Net tel que nous le propose Microsoft , il y a peu d’alternatives aux WebForms pour choisir son moteur de rendu (sinon écrire des composants qui enchainent les ‘ Response.Write’ mais je ne connais personne de sérieux qui se soit lancé dans cette voie là).

Il faut alors chercher sur le web pour trouver des projets indépendants, beaucoup étant inspirés de ce qui se fait dans la communauté Java.

Monorail utilise ASP.Net comme base de fonctionnement. Il est programmé en tant que filtre ISAPI, invoqué par le ASP.Net Worker Process (apnet_wp.exe).

Monorail ressemble fortement à Rails en Java ( et Ruby on Rails) qui a une forte popularité chez les développeurs

Cela se voit en jetant un coup d’œil à leur API respectives :

http://api.rubyonrails.org/

http://www.castleproject.org/monorail/documentation/v1rc2/manual/mrtypedocs/index.html

Monorail propose d’utiliser ActiveRecords qui se base sur Nhibernate. Nhibernate se base quant à lui sur Ado.Net

 

On est loin d’Ado.Net mais toutes ces surcouches sont tout autant de lignes de codes que vous n’avez pas à écrire.

Car au final c’est très simple à utiliser et tout automatique.

Mais on peut tout à fait utiliser tout autre technique d’accès aux données.

 

Et si on a un plus gros projet, et/ou que l’on veut coller à une architecture solide, on aura tantôt fait d’utiliser comme vue un objet de la couche Applicative (Application Layer ou Service Layer comme décrite par Martin Fowler et al.)

Cf mon billet à ce sujet : http://www.dotnetguru2.org/gse/index.php?p=530&more=1&c=1&tb=1&pb=1

Cette couche permet un grand découplage et surtout une séparation de la responsabilité du code (Separation of Concern). Ces objets de la couche applicative sont spécialisés dans le traitement final et haut niveau (c’est à dire le plus prés de l’interface graphique et des actions de l’utilisateur).

Leur fonctionnement est quasi-procédural et n’exposent que des méthodes.

Par contre ces méthodes travaillent (en entrée et en sorties) avec les objets entités (ou data objects).

Il y a une isolation entre les 2. Dans ce type d’architecture les objets entités n’exposent que des propriétés.

Donc dans un modèle MVC/MVP le M de Modèle pourra être un objet «métier» ou Service qui par ses méthodes offrent des capacités métiers (incluant l’inévitable CRUD mais présenté en d’autres termes, en des termes complètement adaptés aux utilisations de haut niveau, c.a.d. IHM et services).

Ce M fera forcément référence a des objets entités qui structurent l’information (comme le fait si bien les objets générés par tout outil de mapping Objet/Relationnel).

 

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :