Dans l’article précédent, je vous ai expliqué pourquoi ASP.NET MVC n’est pas une sur-couche de ASP.NET Webforms.
Lors de mes formations, j’ai très souvent des questions sur les différences entre Webforms et MVC.
Aujourd’hui, je vais vous présenter les différences les plus importantes selon moi.
1. Cycle de vie
Webforms
Le cycle de vie de la requête est fortement basé sur la « page active .aspx ».
Le fonctionnement est géré par des évènements sur lesquels vous pouvez vous abonner.
MVC
Le cycle de vie est différent car il fait intervenir un contrôleur qui va charger des modèles de données puis sélectionner la vue à utiliser pour générer le rendu.
2. Dépendances
Webforms
Les pages sont composées d’une vue et de code-behind. Ceci a un impact important car la vue et le contrôleurs sont fortement dépendants.
MVC
Le contrôleur sélectionne la vue à afficher. Celle-ci ne dépend que du modèle qu’elle va utiliser pour le rendu.
3. Testabilité
Webforms
Les pages sont difficiles à instancier en dehors d’un fonctionnement normal. Ceci a pour effet de les rendre impossible à tester de manière automatique.
MVC
Les contrôleurs sont de « simples » classes que vous pouvez instancier sans contexte Http. Elles sont donc plus faciles à tester avec des tests unitaires par exemple.
4. Gestion de l’état
Webforms
Les contrôles stockent leur état dans le ViewState. Le ViewState est transmis dans chaque page. Il a tendance à grossir très rapidement.
MVC
MVC ne maintient pas d’état des pages, ni de ViewState. Vous avez le contrôle complet de votre application.
5. Les contrôles visuels
Webforms
Webforms est fortement basé sur des composants visuels comme Winforms. Ceci implique que le code est généré de manière automatique (sans grand contrôle).
MVC
MVC n’utilise pas d’évènement ni de code généré. Vous pouvez donc écrire du code HTML propre comme vous le souhaitez.
6. Evènements
Webforms
L’extensibilité est gérée par les évènements. Vous devez donc vous abonner pour modifier certains comportements.
MVC
L’extensibilité est gérée par héritage ou des filtres. Le fonctionnement est simple à comprendre et à débugger.
7. Connaissances HTML, JS et CSS
Webforms
Etant donné la présence de contrôles visuels, vous n’avez pas besoin d’avoir de connaissances approfondies en HTML, JS et CSS pour créer des applications. Les composants vont générer le code pour vous.
MVC
L’absence de contrôles visuels et de drag & drop nécessite des compétences en développement HTML, CSS et Javascript. En contre-partie, vous pourrez écrire du code jQuery et des requêtes Ajax très simplement.
8. Apprentissage
Webforms
Webforms est plus facile à apprendre et permet de créer rapidement des écrans visuels grâce au drag & drop de composants. Le framework est intéressant pour débuter avec le Web quand on connait déjà Winforms.
MVC
Le temps d’apprentissage est un peu plus long car il faut bien comprendre les concepts du framework. Une fois que vous aurez bien compris ces concepts, vous pourrez développer très rapidement des applications web modernes.
Quelques compléments
Postback
Le Postback est une notion utilisée par Webforms mais qui n’existe plus dans MVC.
Le traitement des soumissions de formulaire se fait différemment (merci à David pour la remarque importante).
A vous
A vous de vous exprimer : quelle est la différence la plus importante, selon vous, entre ASP.NET Webforms et ASP.NET MVC ?
Bonjour,
Sympa votre tableau, c’est très clair.
J’ajouterai juste la disparition du postback en MCV, ce qui est parfois la plaie en webFroms.
Aussi, meilleurs intégration de Entity Framework et des interfaces REST en MVC même si ici on s’écarte de la comparaison globale des deux technologies.
En tout cas, bon article et bonne continuation.
Merci David, je vais en profiter pour enrichir la liste avec votre remarque. C’est vrai que j’ai oublié de parler du Postback (qui est souvent une « plaie » et assez difficile à comprendre pour les débutants surtout).
Très bon article !
J’ai déjà plus ou moins donné mon avis dans l’article précédent, mais j’aimerai rajouter une chose, ou plutôt mon coup de cœur pour l’ASP.Net MVC.
Il existe de plus en plus de sites avec des chargements désynchronisés. L’apparition de l’AJAX dans ce domaine a fait beaucoup de bien dans ce domaine.
Seulement, gérer des appels désynchronisés via jQuery sur du WebForms se relève être lourd et fastidieux (mais loin d’être impossible).
Alors qu’en ASP.Net MVC, il est possible d’appeler une action dans le contrôleur en jQuery (en JSON), et cette dernière de renvoyer un résultat exploitable par le script (toujours en JSON). Et ceci de la manière la plus naturelle qu’elle soit, c’est tellement intuitif.
Cerise sur le gâteau, il est ainsi possible de ne rafraichir qu’une toute petite partie de la page, sans avoir à :
– re-balancer toute la page en POST
– se retaper tout le cycle de vie pour arriver à l’évènement
On arrive donc à une page légère en code et très réactive d’un point de vue échange client/serveur (il suffit de voir la timeline réseau des différentes requêtes (temps de réponse, taille de la requête) au travers des consoles de développement des navigateurs).
Merci Florian.
Effectivement, comme vous le dites, pour faire des requêtes AJAX c’est complètement différent de Webforms.
J’ai un article de prévu sur le sujet, à découvrir très bientôt.
je vous remercie pour ces informations , et ce qui m’intéresse beaucoup dans le ASP MVC c’est cette notion :
– il est ainsi possible de ne rafraichir qu’une toute petite partie de la page