Je ne sais pas si toi lecteur hypothétique, tu es familiarisé avec le mécanisme/pattern/philosophie d'ASP.NET. La théorie est donc de nous fournir un point d'entrée, la page, dans laquelle je vais pouvoir utiliser tout un tas de composants web en ignorant royallement le pourquoi du comment html dessous. Il existe tout un mécanisme qui réhydrate tous ces beaux controles de post-back en post-back, évitant ainsi la tâche fastidieuse à chaque post-back de récupérer les données de la requete (http). Ah ça s'ajoute une gestion transparente des événements, qui nous permet donc de nous accrocher à des événements comme le click sur un bouton, ou un index qui change dans une liste.
Visual studio nous fournit une ihm très WISIWIG permettant si on le désir de cacher encore plus toute cette cuisine.

Conclusion? Il est possible avec couple Visual Studio + Web forms de battir extrêmement rapidement une application CRUD simple. Tout ceci s'inscrit dans la mouvence du Rapid Application Development et Smart UI anti pattern... Et voilà tout le problème Je ne pense pas m'avancer en disant qu'il n'existe pas d'applications qui font juste du CRUD (et je pique cette phrase à quelqu'un, mais je ne sais plus à qui donc je m'en excuse).
Quand une application commence à dépasser la dizaine de page, cette approche pronée comme la voie unique de .NET actuellement tend essentiellement à créer de l'inmaintenabilité et du code spaghetti. J'ai vu ainsi des méthodes de gestion d'événement atteindre les... 2000 lignes. Oui le "OnClick" faisait absolument tout, mais tout l'IDE qu'est Visual Studio tend vers ça. Bref je pense que vous trouverez un bien meilleur résumé de ces problèmes dans cet article.

Le problème n'est peut-être pas tant au final la mise en avant de cette approche, mais l'absence d'alternatives pour le moment incluses dans le framwork. Microsoft vient plus ou moins d'annoncer le développement de son propre framework MVC; mais en attendant en entreprise, les applications poubelles et inmaintenables pullulent; et quand on essaye de toucher deux mots sur le côté catastrophique de la futur maintenance, ou nous répond que l'approche officielle microsoft a été utilisée. Je ne vais pas non plus revenir sur le nombre de gens qui font du .NET sans savoir que c'est de l'objet.

Avec le recul je me dis donc que l'apport d'ASP.NET par rapport à ASP n'est pas flagrant si on s'en tient à l'approche officielle par page. Il est même maintenant plus facile de faire une page "à l'ancienne": Ou nous demande une page, donc on l'écrit rapidement et on appelle la procédure stockée ou la table qui va bien derrière pour faire du CRUD, et surtout qu'on nous parle pas de framework métier réutilisable. On peut ainsi se retrouver avec une application de plusieurs milliers de pages sans aucun rapports entre elles, avec autant de procédures stockées et de table. Je sais, j'ai déjà donné.
Pourtant, dans le merveilleux monde de l'architecture logicielle, des réponses ont déjà été trouvées depuis belle lurette, et quelques acharnés nous ont produit des framework pour quitter plus facilement la voie officielle. On peut citer NHibernate, Monorail etc etc. Microsoft finalement est bien au courant de ces problèmes, mais la philosophie du "vous avez tout dans le framework" les oblige à intégrer ces notions avant de les mettre en avant. Bientôt nous trouverons donc le framework MVC made in grossoft ainsi que le framework de mapping objet relationnel, et les boulets alors seront obligés de suivre le mouvement.

On me dirat aussi qu'en Java ces problèmes n'existent pas. Certes, mais Java je trouve, souffre lui d'un problème tout inverse: le trop d'ouverture. Le monde du web en java est une jungle oû coexistent tellement de serveurs d'applications; framework O/R MVC Injection de dépendance etc etc qu'il est impossible pour un nouveau venu de s'y retrouver seul.

Bref je cause je cause, alors que le but d'origine de ce message était de vous parler de Monorail la réponse donc aux limites du modèle de base de ASP.NET (intestabilité, mélange des résponsabilités, inmaintenabilité à long terme, bref tout ce qui est décrit dans l'article plus haut). Monorail est un "classique" framework MVC, où le point d'entrée devient le contrôle et non la page. Donc moi je dis ouf, parce que comme pas mal de monde j'utilisais jusque là le pattern MVP codé maison, comme décrit ici, mais c'était un apport de complexité assez colossal, là ou Monorail garde les avantages de MVP tout en apportant de la simplicité.


PS: un autre article parlant des problèmes d'asp.net la