Ceci est une question périmée avec beaucoup de réponses, mais personne n’a eu la réponse à laquelle je me serais attendu.
La réponse courte est:
- Utilisez ASP.NET MVC si vous souhaitez créer correctement une application Web avec des conventions de programmation modernes et des modèles adaptés à l'industrie pour la plate-forme ASP.NET. En revanche, vous serez censé connaître le fonctionnement du HTML et des ressources côté client (Javascript, CSS), ainsi que la montée en puissance de l’esprit de programmation de MVC, qui nécessite une longue courbe d’apprentissage mais qui, une fois appréhendée, prend fin.
- Utilisez les formulaires Web ASP.NET si vous utilisez ou souhaitez utiliser une approche glisser-déposer du prototypage très rapide à l'aide d'une interface graphique , du développement rapide d'applications (RAD) , c.-à-d. 15 minutes et la solution n'est pas conçue pour être prise en charge par les développeurs. Ou bien, utilisez les formulaires Web ASP.NET si vous avez une expérience en développement d' interface graphique ou Windows Forms et si vous souhaitez transférer vos connaissances sur le Web.
Mais pour bien regarder, vous devez comprendre l'histoire de chacun.
ASP.NET Web Forms était la réponse de Microsoft à ceux qui avaient créé des applications Web dynamiques à l'aide de contrôles ActiveX Visual Basic 6, de DLL VB6 sur le serveur et d'ASP Classic. À l'époque, le développement Web à l'aide de ces outils Microsoft était un véritable gâchis. En plus de l’intégralité du .NET Framework qui était la sortie de Microsoft et qui remontait essentiellement à la conception d’une programmation professionnelle productive sur la pile Windows, ASP.NET Web Forms était, à son époque, incroyable et magnifique.
L’ensemble de l’approche consistait à donner aux développeurs le meilleur des deux mondes, quelque chose de très similaire au développement d’applications Windows, mais avec la puissance des services Internet. L'idée était que, comme avec un "formulaire" VB6 / WinForms (une fenêtre), une page Web est également un formulaire (comme une fenêtre, voyez-vous) et que vous pouvez glisser-déposer des étiquettes, des zones de texte, des grilles de données, des boutons et d'autres éléments auxquels les développeurs de l'interface graphique VB / WinForms étaient habitués.
Pour faire en sorte qu'un bouton fasse quelque chose, après l'avoir fait glisser, il vous suffit de double-cliquer dessus dans le concepteur et de vous retrouver dans l'éditeur de code, en indiquant au formulaire la procédure à suivre lorsque cet événement se produit. C’est exactement ainsi que les développeurs d’interface graphique Windows ont créé un logiciel à l’aide de l’ outil graphique VB6 et d’outils concurrents, à l’ exception du code qui s’exécute sur le serveur! Hou la la!
C'était 2002 technologie. Incroyable et magnifique à son époque en tant que réponse aux solutions d' interface utilisateur graphique activées par Internet pour le développement de RAD , il a apporté un sentiment de puissance à un monde en désordre de développeurs de logiciels qui avaient des objectifs commerciaux à atteindre.
Malheureusement, ce modèle de programmation insiste tellement sur la métaphore de la programmation de l’interface utilisateur graphique de Windows qu’il supporte le fardeau de ses détails de mise en œuvre nécessaires, tous les bagages encombrants nécessaires pour tenir compte du cycle de la vie de l’événement et l’abandon des détails laids du simple code HTML. script que ces composants et contrôles glisser-déposer sortiraient. Et à la fin de la journée, les développeurs supportant des applications réelles devaient inévitablement approfondir ces composants ou écrire les leurs, et par conséquent, ils se battaient avec cette infrastructure, des batailles laissant des piles sur des piles de cheveux crépus, des cheveux tirés, et larmes.
Sauvegarder. Lave t'es mains. Regardons à nouveau le problème de l'entreprise. Quels sont nos objectifs commerciaux?
Nous devons créer et gérer des applications Web . Nos contraintes sont que nous avons le World Wide Web, qui repose sur HTTP, HTML, Javascript et CSS, et sur le serveur, nous avons des règles de gestion, des bases de données et une poignée de grands langages de programmation (par exemple, C #). Avons-nous vraiment besoin de cette métaphore de l’interface graphique Windows pour orienter notre méthodologie de développement? Pourquoi ne pouvons-nous pas simplement nous concentrer sur les problèmes d'application et éliminer les métaphores de l'interface graphique?
C'est là qu'intervient ASP.NET MVC. Il a commencé par une rébellion de développeurs qui s'appelaient eux-mêmes "Alt.Net" et qui souhaitaient revenir à des principes de développement logiciel propres et purs. Fini les complications, concentrez-vous uniquement sur les objectifs commerciaux et les meilleures pratiques en matière de logiciels.
Dans ce cas, cela se traduit réellement par:
- Séparation des préoccupations . Par exemple, un composant de données n'a pas besoin de savoir comment ses données vont être restituées, ni le balisage de vue ne doit être encombré de détails de configuration de connexion de base de données. Ainsi, un développeur peut se concentrer sur son domaine de préoccupation lors de l'édition et de la modification. code de test.
- Exposition et prise en charge complète de l'exposition aux bases du langage HTML et des ressources associées . Dans les formulaires Web, le HTML est caché, ce qui dissuade les développeurs. Dans ASP.NET MVC, les développeurs sont plutôt encouragés à gérer ces détails. en fait c'est une nécessité. L'avantage ici est que le développeur peut réapprendre à apprécier la sémantique propre de HTML, CSS et des scripts, et à l'utiliser avec plutôt que contre elle.
- Testabilité des objets métier . Les contrôleurs et les modèles conviennent beaucoup mieux aux tests unitaires programmatiques, de sorte que les implémentations puissent être validées pour répondre aux objectifs commerciaux et que les modifications puissent être vérifiées pour qu'elles ne se cassent pas. Avec Web Forms, il était difficile de tester les composants, car les composants n'étaient pas conçus pour être testés individuellement et l'ensemble de la sortie de développement tournait autour des formulaires de page et de leur cycle de vie des événements, dans une imbrication de logique métier et de logique de présentation.
Notez que HTML est déjà un langage de balisage de très haut niveau, tout comme Javascript un langage de programmation de haut niveau. L’histoire entière aurait été différente si nous avions traité le langage de l’Assemblée et le C.
En développant # 2, un autre objectif d’ASP.NET MVC est de permettre aux développeurs d’organiser les détails frontaux de la partie "affichage" de leurs solutions et de tirer parti de la base solide sur laquelle le reste du secteur s’appuie. la plate-forme client frontale.
Vous constaterez que les développeurs ASP.NET MVC se sentent chez eux en utilisant de riches bibliothèques Javascript et des techniques de création de modèles côté client sans se heurter à l’architecture côté serveur. Ce n'était pas le cas à l'origine avec ASP.NET Web Forms, car Web Forms ne veut absolument pas que vous consultiez le code HTML ou le script, sauf si vous devez le faire . Dans ce cas, méfiez-vous, ce n'est pas pour le mal de coeur.