Comme l'indique Scott Guthrie sur son blog , hier est sorti la nouvelle preview du framework MVC pour ASP.Net. Pour ceux qui ont un minimum d'architecture dans les pattes et/ou qui ont codé dans d'autres languages (ZendFramework en PHP, Struts en JAVA ou encore Ruby On Rails), le terme MVC sera clair. Pour les autres, plutôt que repartir de zéro, je vous invite à lire le billet de Florent Santin qui présentait, il y a quelques mois déjà, les premières informations que l'on avait sur ce nouveau framework.
En (très) gros, c'est des projets bien structurés en couches et (logiquement) bien propres. On sépare totalement tout ce qui est l'interface, le traitement et la communication. Explication concise par Sébastien Carriere
Cette solution demande par contre une conception bien préparée à l'avance plus ou moins complexe selon l'application, et la séparation complète de la Vue et du Modèle n'est pas toujours des plus évidentes. Cela implique également plus de fichiers. Ca parait trivial mais tous ceux qui auront utiliser cette architecture pourront vous confirmer que cette gestion d'un nombre important de fichiers doit être prise en compte. Côté déboggage, cela peut également être un peu plus complexe. Ce sont de petits incovénients par rapport aux avantages que cela apporte mais néanmoins, ils sont à prendre en compte dans le choix de l'utilisation ou non de cette technique. Il est très rare de voir de petites applications l'utiliser, à moins que vous ne soyez sûrs que ces applications évoluent de façon complexe.
Pour les adeptes de l'ULR Rewriting, vous vous rendrez compte que le modèle MVC utilise les Urls pour envoyer les réquêtes au contrôleur et cela vous permet vous également, de contrôler plus facilement vos URLs.
Fini les www.monappli.com/search.aspx?word=codesources
On aura plutot quelque chose de la forme
www.monappli.com/search/codesources
Sans configurer (ou presque rien) quoi que ce soit. C'est le modèle qui marche ainsi et qui utilise de l'URL mapping.
...
Du moins, c'est ce que l'on retrouve sur les frameworks MVC des autres langages. La question est: l'avons nous en ASP.Net?
La réponse est: la réponse D, à savoir: oui..et non. Oui parce que l'idée est là, non parce que tout n'est pas encore implémenté et des fonctionnalités comme les filtres sur le contrôleur. D'autres choses comme des tags sur vos méthodes comme [AuthenticationRequiredFilter()] (j'explique pas hein :)) et dont l'utilité n'est pas à démontrer sont rajoutés au fur et à mesure des développements sur ce projet. Des fonctionnalités sur le routing ne sont pour l'instant pas disponibles et pourraient ne jamais être présentes.
Voyons maintenant ce qu'il a dans le ventre.
- tout d'abord, une architecture robuste, réutilisation du code facilitée, une organisation plus correcte, en échange d'un travail de conception en amont.
- coté accès aux données, vous pourrez faire votre DAL à l'ancienne ou bien profiter de LINQ to SQL ou to(ut) ce que vous voulez (ouais je fais de jeux de mots pourris si je veux)
- la possibilité de faire des actions dans le contrôleur qui contiendront la logique mais également y utiliser cette logique pour parvenir à un comportement ou un jeu de données qui sera transmis au modèle ou à la vue qui finira le traitement. Très utile pour faire des tests unitaires sur une méthode particulière.
- vous pouvez également utiliser ce que l'on appelle des "méthodes d'aide HTML" (HTML helpers methods) qui sont des méthodes que vous créez vous-même (même si certaines sont proposées de base avec le framework) et qui servent à appeler des méthodes particulières depuis vos templates.
un exemple tout bête. Je pourrais créer un helper qui prend en paramètre un mot clé pour construire un lien de recherche. Ainsi (après avoir codé le code du helper), je pourrais placer un simple
1: <%= HTML.searchLink("Link", new {keyword="toto"}) %>
Pour que la vue me retourne
1: <a href="/search/toto" />Chercher toto</a>
Ceci est bien entendu un exemple ultra simple mais ces helpers vous permettront d'utiliser le contexte pour construire des arguments et passer ces arguments à votre helper qui s'occupera du rendu HTLM final.
- Avec cette release, vous trouverez également de nouvelles fonctionnalités sur le routing dont je parlais plus haut. Nous avons dans cette release comme des methodes (HTML helpers) MapRoute() ou IgnoreRoute(). Ces méthodes, qui s'ajoutent à celles déjà présentes, vous permettent de mieux contrôler les routes de votre application. Ces routes, sont les règles qui se déclenchent en fonction des requêtes qu'enverra le client à travers les URLs. Ici, MapRoute() nous permettra donc d'ajouter une "règle" de plus à celles existantes tandis qu'IgnoreRoute() sert à bloquer le traitement de certaines URLs. L'exemple parfait de Scott:
un simple
1: public void RegisterRoutes(RouteCollection routes)
2: {
3: routes.IgnoreRoute("{resource}.axd/{*path}");
4:
5: //blabla
6: }
empêche que l'application ne traite les fichiers de ressources.
Ce billet ne concerne que les nouveautés et si vous ne l'avez pas encore utilisé, je vous conseille de le faire. Il y a peu, je m'amusais avec Volta et j'avoue avoir été resté sur ma faim (faire des applications Web d'une seule page, ca limite...) mais ici, j'ai apprécié pouvoir le tester et sachant que ca fait déjà quelques mois que je me prend la tête la journée sur une application pour les traders qui devient de plus en plus complexe, je me dis que si ce framework avait été prêt un peu plus tôt, il m'aurait été d'une grande aide.
Liens:
Téléchargement: Setup MVC ASP.Net Preview 3
Code source pour les irréductibles (clin d'oeil à Florent A.): MVC ASP.Net Preview 3 Source code
Site officiel : ASP.Net MVC
