ASP.NET MVC vs. Web Forms

La première version d'ASP.NET fut déployée en 2002, avec le moteur de vue WebForms étant le seul choix disponible. Plus tards, pour supporter des concepts tels que le MVC, Microsoft a étendu ASP.NET pour supporter plusieurs moteurs de Vues, mais epndant plusieurs années, si vous utilisiez ASP.NET, vous utilisiez automatiquement des WebForms.

Microsoft a eu des buts assez discutables quand ils créèrent les WebForms : Ils voulent mettre en abstraction tous les petits détails du protocole HTTP et sa nature sans état pour rendre le développement d'applications Web plus proche du développement d'applications Windows, qui était une expérience plaisante à l'époque.

Ils le firent en introduisant le ViewState, qui se charge d'être certain que l'état actuel d'un formulaire est préservé durant les retours au serveur et ils le firent en utilisant des contrôles serveurs, qui encapsulaient le rendu HTML et CSS dans un contrôle arbitraire que l'on pouvait modifier en utilisant des propriétés logiques plutôt qu'en étant obligé de mélanger HTML et CSS directement.

Ils introduirent également le modèle évènementiel, connu par les développeurs Windows à cette époque, pour autoriser le développeur à répondre à des évènements, comme par exemple un bouton cliqué ou une Checkbox modifiée, plutôt que d'effectuer des vérifications manuelles à chaque fois que la page était rechargée. Ce qui signifie également que le code et l'affichage étaient séparés, ce qui est une bonne chose en théorie.

Là où les Web Forms se sont trompées

Les WebForms furent un bol d'air frais pour beaucoup de développeurs, et cela aida également beaucoup de nouveaux développeurs, ou des développeurs familiers avec les applications client Windows, pour apprendre à créer des application Web. Malheureusement, Microsoft n'a pas réussi à créer l'abstraction parfaite et sans défauts, car un certain nombre de problèmes émergèrent rapidement. Certains d'entre eux ont été corrigés dans des versions ultérieures, pendant que d'autres étaient plus ancrés au fonctionnement des WebForms et donc furent plus difficiles à modifier. La technologie WebForms fut critiquée principalement pour les problèmes suivants :

Le ViewState rend les pages plus lourdes

En gardant une trace de tous les contrôles serveurs dans une page dans une string de ViewState, faisant des allers retours avec le serveur à chaque requête, les WebForms devinrent relativement lourdes. Si vous construisiez une page de complexité moyenne, le ViewState résultant pouvait faire monter la taille de la page de plusieurs centaines de Kilooctets. Ce qui entrainait des temps de chargement plus longs, surtout sur les connexions mobiles, et une augmentation du traffic des téléphones portables partout dans le mode, ce qui est devenu un vrai problème.

Les contrôles serveur limitent vos sorties HTML

Les contrôles serveurs rendent la création de quelque chose d'utile plus simple, mais vous n'aurez jamais un contrôle total du HTML qu'ils rendent. Ceci peut devenir un problème lorsque vous aurez besoin d'ajuster finement votre travail en cas de problème de compatibilité du navigateur.

Les WebForms répondent mal aux tests automatisés.

Le modèle WebForms a été introduit avant que les tests unitaires ne deviennent très utilisés, et quand ils le furent, il est devenu rapidement évident que les tests unitaires sur les WebForms étaient compliqués, pour ne pas dire impossibles.

Là où ASP.NET MVC est une amélioration comparé aux WebForms

ASP.NET MVC supprime énormément d'abstractions implémentées par les WebForms. Par exemple, vous générez généralement tout le HTML vous-même, au lieu de reposer sur des contrôles serveurs. Il n'est donc plus nécessaire de maintenir un ViewState, éliminant de par le fait ce problème (Mais rendant plusieurs contrôles serveurs inutilisables en même temps, comme le GridView et le Repeater).

Le modèle MVC est parfait pour les tests automatisés / unitaires, grâce au couplage léger entre ses différentes couches.

Quelle technologie choisir ?

Il est important de statuer que bien que le WebForm est une technologie dépassée en lisant ce que nous venons de dire, il est encore développé activement par Microsoft et il s'agit toujours d'un choix possible en entrant dans le monde du développemnt Web avec ASP.NET. Les WebForms correspondent particulièrement bien aux situation où vous devez rapidement produire quelque chose de fonctionnel - le nombre élevé de contrôles serveurs avancés rendent plus simple la création de quelque chose à effectuer dans un rush, au prix de la flexibilité que vous offre l'écriture manuelle du code.

Si vous savez déjà comment fonctionne ASP.NET WebForms, vous devriez définitivement essayer ASP.NET MVC, spécialement si certains problèmes mentionnés ci-dessus ont été bloquants dans vos développements. Si vous êtes nouveau dans le monde du développement Web, je vous recommande également d'essayer ASP.NET MVC. Le modèle MVC peut sembler assez restrictif à certaines personnes, et être obligé de suivre une architecture est bien entendu plus difficile au départ que de ne pas en suivre du tout, mais une fois que vous vous y ferez, il sera beaucoup plus agréable de travailler avec et, aux vues de l'attention donnée à l'architecture MVC, il n'est pas prêt de disparaître de sitôt.

Conclusion

Bien que l'ASP.NET WebForms est plus simple à utiliser pour débuter, vous devriez essayer ASP .NET MVC si vous êtes nouveau dans le monde du développement Web. Ne vous en faites pas, ce tutoriel vous aidera à débuter et vous accompagnera dans le processus du développement de votre première application ASP .NET MVC.