- Un modèle (contenant aussi bien des données que des opérations)
- Une vue (responsable de la présentation aux utilisateurs)
- Un contrôleur, dont le rôle est de gérer les événements et la synchronisation entre la Vue et le Modèle
Le pattern MVC a été mis au point en 1979 par Trygve Reenskaug, qui travaillait alors sur SmallTalk. ASP.NET MVC est donc un Framework de développement d'application web, basé sur ce patron de conception.
Le Contrôleur est une classe exposant un certain nombre de fonctions (ou Actions) renvoyant un objet de type ActionResult. Une Action sera toujours le point d'entrée dans ASP.NET MVC, et pourra renvoyer, au choix, une page, des données dans différents formats (binaire, JSON, etc.), voire rien du tout. Les contrôleurs sont stockés dans le répertoire Controllers de l'application Web, et utilisent comme convention de nommage Controller.
Dans le cadre d'ASP.NET MVC, une Vue est l'équivalent d'une page web, utilisant la liaison des données pour afficher des informations. Les vues sont par définitions stockées dans le répertoire Views de l'application Web. Toutes les vues qui seront renvoyées par un contrôleur Controller seront stockées dans le répertoire Views/.
Enfin, le modèle est un ensemble de classes standards dont le but est de gérer un ensemble de données, lesquelles seront ensuite affichées à l'utilisateur. C'est la partie métier de l'application, qui va gérer l'accès aux données, la validation, etc.
Comparaison entre ASP.NET Web Forms et ASP.NET MVC
ASP.NET Web Forms
Comme vue dans le précédent billet sur l'histoire des technologies Web chez Microsoft, les premières versions d'ASP.NET sont basées sur les Web Forms. Celles-ci se basent sur la programmation événementielle, et permettent de développer des applications web avec une approche familière pour des développeurs WinForms. Les principales caractéristiques du développement en Web Forms sont :
- Utilisation du designer (argh !), de nombreux contrôles et désormais de très nombreux outils tiers
- Utilisation du mécanisme des postbacks,
- Utilisation du mécanisme du ViewState,
- Une forte abstraction des contrôles.
ASP.NET MVC
ASP.NET MVC se base sur le paradigme de Reenskaug, déjà appliqué dans de nombreuses technologies autres qu'ASP.NET. Ces caractéristiques sont assez différentes de ce dont les développeurs Web Forms ont l'habitude :
- Contrôle total sur le code HTML généré
- Vues légères sans code behind
- Possibilité des tester les différentes couches
- Moteurs de rendu pluggables (Services Web, médias mobiles, ….)
- Architecture RESTful
- Pas de postback ni de ViewState
Les points communs
ASP.NET Web Forms et ASP.NET MVC se basent tous deux sur la version core d'ASP.NET (voir ce billet pour les nouveautés de la version 4.5). Leurs paradigme respectifs sont très opposés, mais ils partagent tout de même de nombreuses fonctionnalités communes :
- L’authentification
- Les master pages
- La gestion des sessions
- Les profils
- La configuration
- Le caching
- Le routing
- La localisation
- La gestion de l’AJAX
Les différences
En termes d'architecture, d'abord, les deux Frameworks sont basés sur deux patrons bien différents. Si MVC dérive du patron MVC, Web Forms de son côté, est une application du patron de conception contrôleur de page. Le plus gros point différenciateur entre Web Forms et MVC est situé sur la cible initiale de chacun de ces Framework.
Historiquement, ASP.NET Web Forms fut développé pour faciliter la migration des développeurs du monde «stateful» du développement d'applications Windows au monde «stateless» du Web. Pour parvenir à cela, un certain nombre de mécanismes (ViewState, PostBack, contrôles serveurs, cycle de vie complexe de la page) ont été mis en place, de façon à cacher aux développeurs les mécanismes de communication entre le client et le serveur.
De l'autre côté, MVC utilise exclusivement du binding pour communiquer entre un contrôleur et une vue, n'a pas de ViewState, et est par essence stateless. Le cycle de vie, en contrepartie, est plus léger, et le découpage des contrôleurs favorise la conception pilotée par le domaine (DDD, ou Domain Driven Design). De plus, MVC a été pensé pour favoriser les tests unitaires à tous les niveaux, et expose de nombreux points d'extension.
Les avantages et inconvénients d’ASP.NET Web Forms
Les avantages
Le principal avantage des Web Forms aujourd'hui est qu'elles permettent un développement RAD. C'est d'autant plus vrai qu'il existe de nombreux contrôles tiers, payants ou non. Si pour vous la vitesse de développement l'emporte sur la maîtrise du code HTML généré, ou bien si vous aimez l'abstraction fournie par les contrôles ou encore si vous êtes allergiques aux design patterns ou aux tests unitaires, Web Forms est fait pour vous (mais je ne saurais trop vous recommander de vous mettre aux patterns. Si une introduction vous intéresse, c'est ici. De même pour les tests !).
Les inconvénients
Qui dit peu de contrôle sur le code HTML généré dit faible support des standards actuels du Web et ceux à venir. En l'an 2000 cela avait peut-être moins d'importance mais à l'approche de 2012 et avec la multiplication des supports ayant accès au Web c'est primordial !
Les mécanismes du ViewState, du PostBack et l'abstraction liée aux contrôles serveur a un fort impact sur les performances. Même si des optimisations sont possibles, les Web Forms gardent une aura de lourdeur par rapport aux autres technologies Web. On retrouve également cette lourdeur lors du développement. Le cycle de vie des pages et des contrôles est assez complexe pour un débutant, et même les plus expérimentés font parfois des erreurs à cause de cela.
Enfin, l'abstraction existante, la tendance globale à ne pas séparer les couches, ainsi qu'une testabilité médiocre ne font pas des Web Forms l'outil idéal pour les gros projets, ou les projets à forte évolutivité, ou encore à haut risque.
Bien sûr ASP.NET Web Forms évolue constamment et répond encore très bien à de nombreux besoins. La version 4.0 et plus récemment la preview de la version 4.5 amènent un produit plus mature et gérant mieux les standards du Web. Cependant, bon nombre de limitations intrinsèques au paradigme Web Forms demeurent.
Les avantages et inconvénients d’ASP.NET MVC
Les avantages
Comme indiqué plus haut, ASP.NET MVC permet de conserver le contrôle du code HTML généré. Outre le fait que conserver ce contrôle peut être utile dans de nombreuses circonstances (notamment pour assurer la compatibilité avec de nombreux navigateurs), cela apporte d’autres avantages.
Dans la plupart des projets, les développeurs travaillent avec des graphistes, voir des intégrateurs web. Chacun possède son propre domaine de compétences et ce n'est pas à un graphiste ou un intégrateur d'être un expert en développement ASP.NET. L’utilisation du MVC et donc du moteur de templates, permet aux graphistes d’intégrer le design dans les vues sans avoir accès au code métier de l’application. Pas besoin d’apprendre l’ASP.NET, des connaissances de base leur suffisent à mettre en page le site, de la même façon qu'on utilisera Blend dans un projet Silverlight MVVM.
Un autre gros avantage concerne le temps d'exécution serveur qui est fortement réduit. Avec un contrôle poussé sur le code HTML généré, mais aussi une moindre abstraction qu'avec les Web Forms, la taille des pages est amoindrie, de même que son traitement est plus simple (pas de multiples contrôles imbriqués comme avec les contrôles serveurs Web Forms). Pour les sites grande audience ou bien simplement pour le dimensionnement des serveurs frontaux pour la plupart des sites, c'est un avantage primordial.
La liste des avantages est loin de s'arrêter là, en voici les principaux :
- MVC simplifie la gestion d’une application en la divisant en un modèle, une vue et un contrôleur.
- MVC n'utilise pas le viewstate, ou les contrôles serveur. Cela rend le Framework MVC idéal pour les développeurs qui veulent un contrôle total sur le comportement de l'application.
- MVC utilise un pattern Contrôleur frontal (Front Controller), qui traite les requêtes de l'application Web par l'intermédiaire d'un contrôleur unique. Cela permet de concevoir une application qui prend en charge une infrastructure de routage riche.
- MVC offre un meilleur support pour le développement dirigé par les tests (TDD).
- MVC fonctionne bien pour des applications Web développées et soutenues par de grandes équipes de développeurs et de designers, qui ont besoin d'un degré élevé de contrôle sur le comportement des applications.
- MVC offre une structure claire du projet avec la séparation entre les vues, modèles et contrôleurs ainsi que l’utilisation des areas.
- A l’aide du framework MVC, il est facile d’ouvrir l’application à d’autres supports (PC, smart phone, etc.) en proposant un jeu de vues par type d’interface utilisateur, les modèles et contrôleurs n’étant pas impactés.
Les inconvénients
ASP.NET MVC n’est pas une solution clés en mains. Cela peut être considéré comme un avantage, cependant, cela vous oblige à créer un certain nombre de composants vous-mêmes pour être complètement opérationnel.
- Contrairement aux Web Forms, l’état des données entre deux requêtes HTTP n’est pas préservé avec MVC.
- MVC ne permet pas l’utilisation de composants Web comme les GridView (bien que cela n'est plus tout à fait un inconvénient vue le pléthore de Helpers existant désormais)
- MVC nécessite généralement plus de code que pour du développement Web Forms même si ce défaut semble s’atténuer au fil des versions.
Conclusion
ASP.NET Web Forms et ASP.NET MVC sont deux couches de présentation basés sur un paradigme très différent. Chacun ayant ses avantages et inconvénients.
MVC vient d’atteindre un seuil de maturité conséquent suite à la sortie de la version 3 et au preview de la version 4 (voir les nouveautés d'ASP.NET MVC 3). Il est conseillé de se tourner vers ASP.NET MVC plutôt qu’ASP.NET Web Forms pour les objectifs suivants :
- Performance / Scalabilité
- Maintenabilité
- Testabilité
- Evolutivité du code
- Contrôle du HTML généré / Support HTML5
- Utilisation massive d'Ajax
- Intervention d’un designer
Nous n'avons fait que survoler certains concepts et certaines caractéristiques d'ASP.NET MVC. Il reste encore beaucoup de chose à dire. Plutôt que de noyer le lecteur dans les détails théoriques, les prochains billets seront tournés vers la pratique. Nous verrons l'installation de l'environnement de développement, ainsi qu'une première petite application. Ensuite, au fur et à mesure des billets, nous reviendrons sur l'explication des concepts par l'exemple.
N'hésitez pas à commenter cette série pour donner votre avis sur le contenu ou la forme. Je me ferais une joie de prendre en compte vos remarques :-)