Quand privilégier ASP.NET WebForms sur MVC

Je sais que Microsoft a dit

ASP.NET MVC ne remplace pas WebForms.

Et certains développeurs disent que WebForms est plus rapide à développer que MVC. Mais je crois que la vitesse de codage dépend de la technologie, donc je ne veux pas de réponses dans ce sens.

Étant donné qu'ASP.NET MVC donne au développeur davantage de contrôle sur son application, pourquoi WebForms n'est-il pas considéré comme obsolète? Sinon, quand devrais-je privilégier WebForms sur MVC pour un nouveau développement?

Webforms vs MVC semble être un sujet brûlant en ce moment. Tous les gens que je connais prétendent que MVC sera la prochaine grande chose. D'après mes légères traces, cela semble correct, mais non, je ne pense pas que ce sera la fin des formulaires Web.

Mon raisonnement, et celui qui explique pourquoi les formulaires Web seraient choisis plutôt que MVC, ont plus à voir avec une perspective commerciale qu'avec ce qu’il est meilleur que l’autre.

Le temps et l'argent sont les principales raisons pour lesquelles les formulaires Web seraient choisis plutôt que MVC.

Si la plupart des membres de votre équipe connaissent les formulaires Web et que vous n'avez pas le temps de les mettre au point sur MVC, le code généré ne sera peut-être pas de qualité. Apprendre les bases de MVC, puis passer à la vitesse supérieure et faire la page complexe que vous devez faire sont des choses très différentes. La courbe d'apprentissage est élevée, vous devez donc en tenir compte dans votre budget.

Si vous avez un grand site Web écrit entièrement en formulaires Web, vous serez peut-être plus enclin à créer de nouvelles pages dans les formulaires Web afin de ne pas avoir deux types de pages très différents sur votre site.

Je ne dis pas que c'est une approche tout ou rien, mais cela rend votre code plus difficile à maintenir en cas de scission des deux, en particulier si tous les membres de l'équipe ne connaissent pas MVC.

Mon entreprise a récemment réalisé trois pages de test avec MVC. Nous nous sommes assis et les avons conçus. Un problème que nous avons rencontré est que la plupart de nos écrans ont les fonctionnalités View et Edit sur la même page. Nous avons fini par avoir besoin de plus d'un formulaire sur la page. Pas de biggy, sauf que nous n'utiliserions pas notre page principale. Nous avons dû procéder à une refonte afin que les pages de formulaires Web et les pages MVC puissent utiliser la même page maître pour une apparence et une convivialité communes. Nous avons maintenant une couche supplémentaire d'imbrication.

Nous devions créer une toute nouvelle structure de dossiers pour ces pages afin que celle-ci suive la séparation MVC appropriée.

Je pensais qu'il y avait trop de fichiers pour 3 pages, mais c'est mon opinion personnelle.

À mon avis, vous choisiriez les formulaires Web plutôt que MVC si vous n'avez pas le temps / l'argent nécessaire pour investir dans la mise à jour de votre site afin d'utiliser MVC. Si vous utilisez une approche semi-arse, cela ne sera pas mieux que les formulaires Web que vous avez actuellement. Pire encore, vous pourriez même mettre cette technologie en échec dans votre entreprise si elle est gâchée, car la haute direction pourrait la considérer comme quelque chose de inférieur à ce qu’elle sait.

J'ai développé des applications ASP .Net WebForms pendant 3 ans et, après une journée de formation à un tutoriel MVC, j'ai été vendu. MVC est presque TOUJOURS la meilleure solution. Pourquoi?

• La vie de page est plus simple et plus efficace
• Il n’existe pas de contrôles en plus des contrôles HTML. Vous n'avez pas besoin de déboguer votre sortie pour voir ce que génère ASP .Net.
• ViewModels vous donne un pouvoir immense, évite la nécessité de lier manuellement les commandes et élimine de nombreuses erreurs liées à la liaison.
• Vous pouvez avoir plusieurs formulaires sur une page. C'était une limitation sérieuse de WebForms.
• Le Web est sans état et MVC correspond plus étroitement à l'architecture du Web. Les formulaires Web introduisent l’état et les bugs que vous rencontrez en introduisant ViewState. ViewState est automatique et fonctionne en arrière-plan, de sorte qu'il ne se comporte pas toujours comme vous le souhaitez.
• Les applications Web doivent fonctionner avec ajax ces jours-ci. Il n'est plus acceptable d'avoir des chargements de page complets. MVC rend ajax tellement mieux, plus facile et plus efficace avec JQuery.
• Étant donné que vous pouvez avoir plusieurs formulaires sur une page et que l'architecture repose sur des appels à des URL, vous pouvez effectuer des opérations amusantes telles qu'ajax charger un formulaire différent, comme un formulaire de modification dans votre page actuelle à l'aide de JQuery. Une fois que vous réalisez ce que cela vous permet de faire, vous pouvez faire des choses étonnantes facilement.
• ASP .Net WebForms n’est pas seulement une abstraction sur HTML, il est extrêmement complexe. Parfois, vous obteniez un bogue étrange et le combattiez plus longtemps que nécessaire. Dans de nombreux cas, vous pouvez réellement voir ce que cela fait de mal, mais vous ne pouvez rien y faire. Vous finissez par faire des solutions de rechange bizarres.
• WebForms ne constitue pas une bonne technologie pour les concepteurs. Les concepteurs aiment souvent travailler directement avec le langage HTML. Dans MVC, c'est une vue, dans WebForm, c'est une demi-journée de travail.
• Comme la plate-forme Web évolue rapidement, WebForms ne suivra pas. Il n'est pas au courant des nouvelles balises ou fonctionnalités de HTML5, il restitue le même rendu, sauf si vous obtenez (souvent) des contrôles tiers coûteux ou attendez que Microsoft publie une mise à jour.
• Les contrôles dans WebForms vous limitent de nombreuses façons. Dans MVC, vous pouvez simplement récupérer une bibliothèque JQuery et l'intégrer à vos modèles.

Je sais que certains des problèmes ci-dessus ont été résolus dans une certaine mesure à mesure que WebForms évolue, mais c'était mon expérience initiale. Globalement, je trouverais extrêmement difficile de trouver une analyse de rentabilisation pour WebForms à moins qu’un projet ne l’utilise déjà.

J'ai envoyé un courrier électronique à Scott Guthrie , expert MVC chez Microsoft. Et probablement l'homme le plus qualifié pour répondre à cette question. Il a eu la gentillesse de répondre:

"Différents clients recherchent différentes approches en matière de programmation, et beaucoup adorent WebForms et le trouvent formidable. D'autres apprécient MVC et le trouvent formidable. C'est pourquoi nous investissons dans les deux."

Donc, pour moi, cela signifie que ce n'est pas un problème technique. C’est plutôt un «problème modéré», si vous voulez. Une de préférence personnelle. Cela correspond à ce que plusieurs d’entre vous ont dit.

Merci pour toutes les réponses.

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:

1. 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.
2. 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.
3. 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.

Je suis une conversion complète et totale vers ASP.NET MVC et je n’ai pas regardé en arrière, ce qui signifie que je dois toujours maintenir plusieurs très grandes applications WebForms. Voici mon point de vue sur elle:

WebForms
Utilisez-les lorsque vous avez des problèmes sérieux à faire avec les grilles. Les contrôles de la grille sont vraiment très utiles lorsque vous avez un jeu de données simple qui s’intègre parfaitement dans un format tabulaire et que vous souhaitez fournir un moyen simple aux utilisateurs de mettre à jour les enregistrements. Oui, je sais que MVC 4 possède une liste de type liste très attrayante pour Ajax que vous pouvez utiliser et qui fonctionne très bien, mais dans notre secteur, nous avons souvent besoin de faire fonctionner quelque chose hier et de bonnes grilles à l'ancienne fonctionnent très bien et les utilisateurs sont heureux d'être heureux. capable de parcourir une grille avec joie. Pour moi, c'est vraiment la meilleure chose à propos de WebForms; mais, comme Ryansouligné WebForm peut être un désordre important parce que vous jouez les deux côtés de la clôture à partir d'un fichier code-behind astucieux. Ce peut être à la fois une rose et une épine de garder tout votre contenu de type contrôleur mélangé à votre vue.

MVC
Utilisez-le lorsque vous voulez vraiment lancer le vôtre et que vous avez la possibilité de démarrer une application à partir de zéro. Avoir une application MVC clairement définie demande un peu plus de travail, mais ses avantages en termes de facilité de maintenance dépassent les coûts de configuration initiaux. Si vous souhaitez effectuer des interactions intéressantes avec Ajax, préférez écrire votre modèle avec du code, comme des URL et des itinéraires propres, et pouvoir contrôler le flux complet de votre application, c'est le choix qu'il vous faut. Il faut s’y habituer au début, mais je pense que c’est la meilleure option pour les applications nouvelles.

En conclusion, pour moi, il s’agit de grilles et de grilles. :)

Mon expérience:

• A écrit des projets CakePHP pendant un an.
• Achèvement d'un projet de formulaires Web de taille moyenne sur six mois.
• Travaillé sur un projet Windows Forms pendant trois ans.

Après cette expérience, j’ai essayé d’écrire une autre application à l’aide de formulaires Web, mais j’ai été frustré après avoir passé une journée à lutter contre la façon dont les formulaires Web tentent de protéger le développeur du fait qu’ils développent une application utilisant HTML, javascript et css.

J'ai ensuite essayé MVC, et ayant un contrôle plus direct sur la sortie (et une certaine expérience du paradigme MVC de CakePHP), j'ai pu compléter cette application simple exactement comme je le voulais en environ une demi-journée.

La disponibilité de puissants frameworks d'interface utilisateur tels que jQuery élimine considérablement l'attrait d'abandonner le contrôle direct de la sortie au profit de composants d'interface utilisateur prédéfinis souvent volumineux.

Je préfère les formulaires Web car mon arrière-plan est le développement Windows.

La vitesse de développement est un problème clé, et je peux facilement passer le problème à une personne en Inde pour qu’elle répare du jour au lendemain avec des formulaires. De plus, si j’ai un problème de vitesse sur une page, un très bon livre sur asp.net speed est pratique (Rick Kiessig est l'homme).

webforms est pour ex windows windows mvc est pour web people

mais, dans le monde moderne, où Rick a écrit un livre génial, avec des serveurs de plus en plus rapides et des codeurs bon marché en Inde, eh bien, les formulaires Web ont l'avantage

Mon 2 centimes est de toujours utiliser ASP.NET MVC pour les nouveaux projets si vous avez l'option. À mon avis, les formulaires Web ne sont pas un bon moyen de développer des applications Web, point à la ligne.

Je pense que résumer loin du REST de base est mauvais, le modèle de publication dans son ensemble est mauvais, la façon dont html / css est utilisé avec une confiance dans l'éditeur d'interface graphique est mauvaise, l'accent mis sur des éléments tels que des assistants et des interfaces graphiques pour configurer est mauvais, les URL sont mauvais.

J'ai lu toutes les réponses et je pense que mon expérience personnelle ajouterait quelque chose aux réponses ci-dessus.

Il y a trois ou quatre ans, j'ai développé deux ou trois projets de sites Web à l'aide de Webforms. À cette époque, MVC n'était pas là ou je n'en avais pas entendu parler. Le développement a naturellement été rapide (je venais du développement de Win-forms sans expérience préalable en développement Web), car je n'avais pas besoin d'apprendre le HTML en détail et les contrôles Web étaient d'une grande aide (beaucoup, cela simplifiait la vie). .

Maintenant, après tout ce temps, je ne travaillais à aucun projet Web jusqu'à récemment et je construisais simplement une application Windows à l'aide de WPF.

Il y a quelques jours, j'avais une idée de site Web et je pensais le développer: cette fois-ci dans MVC (car on en parle partout, je devais apprendre non plus, alors j'ai choisi MVC). Le projet est encore en phase de développement, car je suis toujours en train d'apprendre et de construire ensemble.

Donc, les principales différences que je trouve n / b les deux sont les suivantes: -

• Pour les personnes venant du développement Windows, les formulaires Web seront toujours favorables. La courbe d'apprentissage d'Asp.net pour un développeur Windows est un peu raide

• MVC sera privilégié pour les personnes issues du développement Web utilisant une autre technologie, car il se moque du dernier.

• Le développement est plus facile et plus propre dans MVC si vous possédez une bonne connaissance du HTML et du CSS

• Le déploiement est toujours un problème. Dans les formulaires Web, il suffit de copier-coller. Mais, cela nécessite certaines choses à faire.

En bref, les deux vont rester ici pendant un moment.

Je n'ai pas encore vu cette considération parmi les 15 réponses existantes à ce sujet, mais je pense que cela vaut la peine d'être considéré.

D'après mon expérience, Web Forms est plus similaire à Win Forms et WPF que MVC. Compte tenu de cela, je pense que l’on pourrait envisager de choisir Web Forms lorsque l’équipe a la plus grande expérience de ce type de technologie ou lorsque le projet Web Forms fournira une interface au même ensemble de données qu’un Win Forms existant (ou développé simultanément). Projet WPF. Cela permet aux développeurs de passer plus facilement d'un projet à l'autre, car la logique de l'application peut être assez similaire entre les deux.

Comme d'autres réponses l'ont souligné, le développement sur le framework MVC s'apparente davantage au développement web en Ruby, PHP, Python, etc. que ses homologues Microsoft; Le choix de MVC peut donc naturellement être influencé par l'expérience des équipes dans ces domaines, ainsi que par les facteurs présentés dans d'autres réponses.

La raison pour laquelle nous n’avons pas fait appel à MVC il ya quelques années est qu’il s’agissait d’une technologie immature de Microsoft. Au cours des dernières années, nous en sommes maintenant à une version plus mature (4) et MS semble avoir compris où il veut en venir. Cependant, nous sommes toujours réticents à développer des applications LOB majeures utilisant MVC, car les fonctionnalités que nous souhaitons utiliser dans la version 4 nécessitent un serveur Windows 2012 (pour les sockets Web via IIS8). Je pense que dans un an, nous accepterons davantage MVC car nous espérons que davantage de contrôles par des tiers seront disponibles, que la technologie sera installée et que nous aurons l'infrastructure nécessaire pour la prendre en charge.

Cette décision dépend de vos préférences, de vos exigences, voire de vos connaissances et de votre expérience.

Le temps nécessaire pour former MVC ou le temps nécessaire pour obtenir une prestation. Toutes ces choses sont importantes pour choisir l’une ou l’autre approche.

N’est-ce pas que l’un est meilleur qu’un autre, simplement l’approches ou les cadres ont des avantages et des inconvénients.

Personnellement, je préfère MVC 3, je vous recommande d’essayer de vivre votre propre expérience, mais je dois dire que ce programme dans MVC est un moyen propre, amusant, flexible, extensible, sécurisé et structuré.

Cordialement,

La seule raison pour laquelle je choisirais les WebForms au lieu de MVC est que vous disposez de beaucoup plus de contrôles d'interface utilisateur tiers pour WebForm que de MVC. J'ai choisi MVC parce que j'ai trop travaillé avec WebForms et que je veux travailler avec quelque chose de nouveau / frais, mais toujours dans MS Shop :)

Fondamentalement, rien ne vous empêche de désactiver l'état d'affichage dans WebForms et d'utiliser les boucles ViewModels et if / for à la place de la liaison de modèle et des contrôles côté serveur.

S'agit-il du code WebForms ou MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

La seule limitation que j'ai trouvée dans WebForms est que si vous utilisez Dependency Injection / Inversion of Control, vous ne pouvez pas avoir d'injection de constructeur car les pages WebForms doivent avoir un constructeur sans paramètre, vous devez donc utiliser l'injection de propriété. Est-ce vraiment un gros problème?

ASP.NET MVC est vraiment une réponse à Ruby, et au nouveau moyen, à la fois tendance et mieux (IMO), de découpler le navigateur (client) du serveur autant que possible.

Les formulaires Web ASP.NET vous donnent beaucoup de contrôle sur le client côté serveur, avec un accès direct à peu près tout. Essentiellement, votre vue et votre contrôleur sont identiques, ce qui vous donne beaucoup de puissance et beaucoup de dégâts.

ASP.NET MVC sépare la vue et le contrôleur en dissociant le couplage étroit entre un fichier .aspx et le fichier .aspx.cs qui les accompagne dans les formulaires Web.

La différence réside essentiellement dans le fait que vous avez beaucoup plus de traitements (généralement la totalité) pour afficher les données dans le fichier de vue, et à laisser la logique métier et le reste dans le contrôleur, en les conservant tous les deux plus propres par convention, mais aussi avec un accès moindre à chacun. permet autre que webforms.

À mon avis, ils sont suffisamment liés et ont à peu près les mêmes capacités qu’il devrait en résulter une préférence.

Un excellent développeur WebForms peut produire un produit aussi puissant qu'un excellent développeur MVC. Mais le grand développeur WebForms qui essaie de se forcer à adopter MVC va échouer. Il en va de même pour un excellent développeur MVC donnant un coup de pouce à WebForms.

Ce ne sont pas des entités complètement distinctes et, tant que Microsoft continuera de prendre en charge les deux systèmes, je pense que vous continuerez à voir un groupe mixte de développeurs exceptionnels pour chacun.

Tout est une question de choix personnel, en supposant que nous maîtrisons tous la technologie que nous utilisons. J'utilise l'approche de conception WebForms depuis de nombreuses années et je dois dire que le seul inconvénient est qu'en raison de son approche simpliste, de nombreuses personnes ne prennent pas le temps de découvrir ses vastes capacités.

J'ai récemment utilisé MVC pour mener à bien un projet et, bien que j'aime bien l'approche de conception du développement d'applications (qui vous donne plus de contrôle, des URLs propres, SOC, etc.), elle ne fournit pas grand-chose, ni WebForms. En fait, l’émergence de jQuery et son fonctionnement avec WebForms (ainsi que MVC) ont rendu ces arguments moins problématiques. Et quand les gens parlent de la séparation des préoccupations comme d’un avantage de MVC sur MVP, je leur demande quelle connaissance ils ont de la programmation orientée objet et de quelle manière ils ont appliqué le principe de l’abstraction et du polymorphisme.

Je suis actuellement à l'aise avec les deux technologies et je choisis en fonction de la situation. Franchement, c’est à vous de décider, mais la vérité demeure que tout le monde ne prend pas son temps pour apprendre en profondeur de quoi une technologie particulière est capable.

Face à un problème de programmation, je cherche souvent des réponses sur le Web. Les formulaires Web contiennent des tonnes d'informations et de composants permettant de faire à peu près n'importe quoi. En raison du nombre réduit de sources en ligne et des couches d’abstractions nécessaires au bon fonctionnement de MVC, MVC a limité les tâches que je pouvais faire jadis. MVC Total tue ma productivité en tant que développeur alors qu'avec Webform, ce n'est pas le cas. Donc, pour l'instant, je m'en tiens aux formulaires Web jusqu'à ce que MVC ait suffisamment mûri pour le remplacer.

Eh bien, les WebForm ont davantage de ressources d’apprentissage disponibles (tout simplement parce qu’elles sont plus anciennes) et donc les nouveaux programmeurs qui ne sont pas "au courant" auront plus de chances de trouver des informations sur cette technologie plus ancienne, par opposition aux éléments plus récents tels que MVC. .

Les programmeurs expérimentés / expérimentés sont plus âgés et maîtriseront mieux les technologies plus anciennes car ils y ont programmé plus longtemps que dans la nouvelle.

Si vous ne dépensez pas l’argent et les efforts nécessaires pour que vos collaborateurs maîtrisent autant le système MVC que les applications WebForms, vous tenterez sans aucun doute de mettre à niveau la mise à niveau vers la nouvelle plate-forme le plus longtemps possible.

Cela pose donc plusieurs problèmes logistiques: Les avantages de MVC l'emportent-ils sur les coûts en termes de qualité moindre et de temps de déploiement? Si mon site est entièrement écrit en WebForms, est-ce que cela en vaudrait la peine d'investir du temps et de l'argent pour intégrer MVC?

Comme indiqué par un intervenant précédent, MVC vous empêche également d’obtenir le même niveau d’interface avec le contrôleur que vous le pourriez avec WebForms. Bien que je sois pour l’objet «Empêcher les utilisateurs d’empêcher l’apprentissage», il peut toujours être excessivement gênant pour les équipes de déployer / mettre en œuvre un programme qui adhère fanatiquement à ce paradigme pour tout ce qu’elles écrivent.

Je pense que l’écart entre ces deux technologies n’est plus aussi vaste qu’il était.

• Les formulaires Web peuvent utiliser le moteur de routage utilisé par MVC (ou quelque chose de très similaire).
• Le gestionnaire de scripts peut combiner des scripts, charger à partir d'un CDN et même retarder le chargement des scripts.

Pour répondre directement à votre question, je pense que cela dépend de la préférence et / ou de la nature du projet. Ils adoptent tous deux une approche du développement très différente. Personnellement, je travaille sur MVC, mais j'aime toujours travailler avec les formulaires Web. Je pense que vous devez utiliser MVC ou Webforms pour décider si vous voulez faire l'expérience des deux technologies.