ASP.NET MVC2 - Introduction

Introduction :

J’ai décidé de créer une petite série afin de vous montrer les nouveautés ASP.NET MVC2. De nombreux blogs fleurissent sur ASP.NET MVC ces temps-ci, principalement en anglais et il me semblait que la qualité d’information en langue française manquait quelque peu. J’aurais pu continuer mon blog en anglais comme j’avais d’ailleurs débuté à le faire il y a quelques temps. Néanmoins, après avoir discuté avec certains collèges et amis, j’en suis venu à la conclusion qu’il était peut-être plus utile que je m’exprime dans ma langue maternelle. J’aurai, en effet, plus de facilité à vous expliquer les différents aspects de MVC2.

Nous sommes le 15 Mars 2010 et hier, ASP.NET MVC2 a été délivré et oui, bonne nouvelle, nous pouvons enfin l’utiliser en production. Dans cette série, je créerai un CMS, oui réinventer la roue, mais ce concept compris de tous sera donc plus facile pour vous d’assimiler les nouveautés que nous apportent ASP.NET MVC.

Qu’en est-il de ASP.NET Webform ?

Rassurez-vous, ASP.NET MVC ne va pas remplacer les webforms, il est juste un autre type d’application que nous fournit Microsoft. Les améliorations pour les Webforms continueront. D’ailleurs, il y a pas mal de nouveauté très sympa avec le nouveau ASP.NET 4.0 (je pense au ClientMode ID, le routing, etc…).

Pourquoi donc apprendre ASP.NET MVC ?

Oui vous pourriez bien continuer à utiliser les webforms classique mais vous rateriez quelque chose. Je m’explique, si vous êtes développeur ASP.NET, vous êtes donc, que vous le vouliez ou non, un développeur Web. Votre client est bien un site web. Dans ce cas, je pense que vous devez tenir compte d’une certaine philosophie web. Par exemple, respecter les standards du web, utiliser du Javascript, avoir connaissance des requêtes html envoyées au serveur, utilisez du CSS pour créer votre design,…

Les webforms nous fournissent un outil utile mais il a été pensé de la même manière que les winform. En effet, ASP.NET fournit une couche d’abstraction de la couche ui. Vous pourriez donc bien écrire une application ASP.NET sans écrire le moindre code HTML. Cette couche d’abstraction est peut-être utile. En effet, pas besoin de savoir ce qui se passe derrière, plus besoin de connaître les requêtes http que nous recevons du client, ni celle que nous envoyons au client, tout se passe comme par magie. Nous n’avons plus qu’à mettre notre code dans le codebehind de notre page. Mais cette abstraction a un prix. En effet, tenter de fonctionner dans un esprit « statefull » (comme winform) dans un environnement qui est stateless (le web, client/serveur web) nous coûte quelques contraintes.

Pour commencer le viewstate, il est l’un des mécanismes qui nous permet de faire le lien entre l’orienté objet et le html. Il va, par exemple, détecter les changements intervenus à la page. (plus d’information sur le viewstate, ici : http://www.dotnetguru.org/articles/dossiers/viewstate/viewstate.htm). À chaque action, un postback sera exécuté et transférera l’entièreté du ViewState vers le serveur web. Il pourra atteindre quelques milliers de kylobytes et ainsi « alourdir » l’application. Utiliser l’Ajax par ce principe est aussi paradoxal, il n’est pas dans la philosophie ajax (optimiser les requêtes entre le client et serveur et ce, de manière asynchrone).

Un autre point qui permet la communication entre le client et le serveur est le « page life cycle ». Cette série d’événements clients, serveurs peut devenir très vite difficile à comprendre pour des applications complexes. Je suis certain que vous êtes un spécialiste du «page view cycle » mais, personnellement, j’ai déjà passé quelques heures à comprendre pourquoi un de mes «events handlers » ne s’étaient pas exécuté.

Déposer un gridview dans le designer et lui connecter un objectdatasource, rien de plus facile pour faire vite mais quel contrôle avons-nous sur le html généré? Ce html est parfois généré de manière douteuse et peu standard. Ne parlons pas des ID générés de parfois plus de 50 caractères qui ne seront pas facile à intercepter en utiliser javascript et encore moins pour le CSS.

Le code-behind de la page qui entraîne des applications fortement couplées entre la vue et la partie logique. En effet, il n’est pas rare d’avoir du code qui manipule des données depuis une base de données directement dans le load d’une page. Quelques patterns nous permettent de remédier à la situation mais ils sont, selon moi, non encouragés de part l’architecture des webforms. De plus, ASP.NET mène au mixte entre le code ASP compris directement dans la vue et nos objets se trouvant dans le code-behind de la page. Il en résulte un couplage fort entre vue et logique serveur. Cela nous donne des applications difficilement maintenables et fragiles à l’extension.

Un code difficilement testable. Avec l’émergence des méthodologies Agile, le pattern TDD devient peu à peu un standard dans le monde du développement. En effet, qui n’a jamais entendu parler de tests unitaires ou d’outils de mocking à l’heure d’aujourd’hui? Construire du code robuste et tester avant même sa mise en QA est devenu banal. Cette manière de faire nous est impossible (ou presque) en winforms. En effet, l’architecture n’a pas été pensée dans ce but.

Je suis certain qu’ASP.NET continuera à être amélioré au fur et à mesure des releases. Des progrès sont à noter avec le contrôle d’un HTML plus propre possible avec ASP.NET 4.0 mais son gros point faible restera toujours sa non-testabilité (pour le moment).

ASP.NET MVC, lui, plus nouveau, a été pensé dans une autre philosophie, celle des méthodologies Agile, du TDD, des IOC/Dependency Injection, du respect des standards web, du protocole REST,…

Microsoft a répondu à ses développeurs et à ses détracteurs en nous donnant le choix d’utiliser ASP.NET MVC.

Le succès connu ces derniers temps par Ruby on Rails (open source) ne doit pas être totalement anodin. En appliquant les dernières mouvances du développement web, une architecture MVC, en travaillant avec les requêtes http et non en les rendant abstraites et en intégrant un ORM en son cœur, Ruby on Rails est vite devenu une coqueluche auprès des développeurs web. Certains développeurs ASP.NET connus de la communauté comme Rob Connery se sont même converti vers cette technologie. Je vous conseille, d’ailleurs d’y jeter un œil.d Ruby on Rails est très intuitif et pour l’avoir essayé, c’est un framework agréable totalement dédié au web.

Les avantages du ASP.NET MVC :

Justement le MVC :

Le model-view-controller est un pattern connu depuis longtemps dans la communauté des développeurs orientés objets, il a été introduit en 1978 dans le projet SmallTalk et est maintenant très populaire dans le monde du développement web.

-Les interactions entre utilisateurs et serveurs prennent un cycle naturel. L’utilisateur émet une action, en réponse le serveur change sont modèle et retourne une vue mise à jour par l’utilisateur. Et le cycle se répète indéfiniment, très pratique pour les applications web qui ne sont finalement que des séries de requêtes http échangées entre client et serveur.

-Une application est un système complexe, il est la résultante de différentes technologies, en effet, en tant que développeur web .NET, vous devez maîtriser le HTML, le CSS, le javascript, l’ASP.NET, le C# (ou le VB.NET), des connaissances en orienté-objet et des connaissances en base de données. Une application en couche est donc la moindre des choses pour ce genre d’application et le pattern MVC se marie assez bien dans des architectures multicouches.

Un système extensible à souhait :

ASP.NET MVC a été bâti dans une philosophie Agile, il est extensible. En effet, l’ASP.NET MVC est un ensemble de composant mis à votre disposition pour répondre à vos envies de développeurs web. En utilisant interfaces et classes abstraites, le framework nous donne donc la possibilité de remplacer facilement les composants que nous voulons changer pour x ou y raisons. Vous allez donc pouvoir changer le routing system, le view engine, le controller factory et ainsi de suite. Cela tout simplement en implémentant les interfaces et les classes abstraites adéquates. De manière générale, ASP.NET MVC nous donne ces solutions :

-Utilisez le fonctionnement par défaut.

-Dériver une sous-classe de l’implémentation par défaut en vue de changer légèrement le comportement de celui-ci.

-Remplacer entièrement un composant avec une nouvelle implémentation des interfaces et des classes abstraites fournies. Un peu comme le Provider modèle fourni en ASP.NET 2.0.

Un système testable:

L’architecture MVC nous donne des applications qui seront facilement testables mais aussi facilement maintenables (par la séparation des différentes couches). De plus, il nous permet de facilement « mocker » chaque partie du framework. Nous verrons cela plus tard dans notre série.

Le contrôle du HTML généré:

En fait, c’est assez simple, vous êtes maintenant maître du HTML produit. Plus d’id mirobolant, plus de viewstate, vous pouvez maintenant produire du code hautement standard et donc plus facilement maintenable. De part cette aspect, vous pourrez maintenant très facilement reprendre le HTML fourni par votre intégrateur (si ce n’est vous-même) dans vos vues. Vous allez pouvoir construire votre design sans vous souciez qu’il soit écrit en ASP.NET, en PHP, en Ruby ou que sais-je. Par ce contrôle sur le HTML, vous pourrez donc très facilement y intégrer des plugins javascript. Microsoft ne s’y est d’ailleurs pas privé en vous fournisseurs dès le départ Jquery. Vous allez vois, l’essayer, c’est l’adopter.

Des URL propres:

De nos jours, les url propres sont devenues une demande classique dans les solutions web. Les searchengines donnent un poids conséquent aux mots clés compris dans les url, ce qui en fait un requis pour le recensement. Des urls propres donnent également la possibilité de naviguer directement depuis la barre d’adresse de votre navigateur. De même, ils entraînent plus de confiance envers votre site. La peur de partager des liens sans donnée personnelle deviendra inexistante. ASP.NET MVC, nous fournit un composant puissant et malléable afin de mettre en place ce système de liens propres. La classe system.web.routing, vous aurez un contrôle total de vos liens, il sera donc aisé de coller au protocole REST.

La puissance du framework .NET:

ASP.NET MVC vous donne les mêmes droits sur le framework que l’ASP.NET. Aucune restriction concernant son utilisation. De plus, vos anciens contrôles développés en webform pourront continuer à coexister avec ASP.NET MVC. Le déploiement d’ASP.NET MVC se fera peu ou prou de la même manière qu’une application ASP.NET classique, il vous faudra juste installer la bonne version d’ASP.NET MVC sur votre serveur.

Open source :

Vous voulez aller plus loin et comprendre comment a été conçu le Framework ? Rien ne vous empêche de prendre le code source d’ASP.NET MVC et de référencer celui-ci dans votre solution. Vous êtes alors prêt à explorer les moindres recoins du Framework. En effet, ces sources sont publiées sous une licence Ms-PL, ce qui implique que vous pouvez changer le code source à votre grès et même le redistribuer comme projet dérivé. Par contre, Microsoft n’acceptera pas les patchs effectués par la communauté. En effet, Ms veut rester maître de son produit.

NB : si vous voulez le code source d’ASP .NET MVC2, veuillez vous rendre sur cette page. Il vous suffit alors de télécharger le fichier mv2-ms-ps.zip.

En conclusion:

J’ai voulu commencer cette série par une partie assez théorique, j’espère que cet article vous aura donné l’eau à la bouche. Je ne dirai pas que ASP.NET MVC est un Framework révolutionnaire. Microsoft n’a finalement fait que reprendre les principales mouvances actuelles du monde du développement web. Mais n’est-ce pas déjà là un grand pas ? En effet, il semblerait que le respect des standards, l’aspect testable et d’extensibilité aient gagné Microsoft. Après des évolutions majeures telles que Linq, Entity Framework, WCF, Silverlight, ASP.NET MVC est assurément une nouveauté d’un poids comparable aux précités.

Plus personnellement, développant des applications en ASP.NET MVC depuis bientôt plus d’un an, je suis toujours aussi conquis par ce framework. Je profite donc de la sortie du release 2 d’ASP.NET MVC pour vous faire partager mes connaissances acquises ses derniers temps. Le prochain article se concentrera sur l’installation de Visual Studio 2010, du framework ASP.NET MVC2 et d’une application de style « hello word » . Ceci afin de vous faire comprendre les principes de vue, de modèle et de controller. Ces bases acquises, je tenterai de continuer cette série par le développement d’un CMS en utilisant les dernières technologies de Microsoft tout en respectant une certaine philosophie agile (TDD, à l’écoute des changements). J’attendrai, bien évidement de votre part un retour constructif afin de me guider au mieux dans ce périple.

Références :

Pro ASP.NET MVC Framework de Steven Sanderson, le bog de mr Rob Conery, le blog de mr Phil Haack, le blog de mr Scott Guthrie et ASP.NET.