Quand privilégier les WebForms ASP.NET par rapport à MVC

Webforms vs MVC semble être un sujet brûlant en ce moment. Tout le monde que je connais vante MVC pour être la prochaine grande chose. Daprès mes légères touches, cela semble correct, mais non, je ne pense pas que ce sera la fin des formulaires Web.

Mon raisonnement, et le raisonnement quant à la raison pour laquelle les formulaires Web seraient choisis plutôt que MVC, a plus à faire avec une perspective commerciale plutôt que ce que lun est meilleur que lautre.

Le temps / largent sont les principales raisons pour lesquelles les formulaires Web seraient choisis plutôt que MVC.

Si la plupart de vos Léquipe connaît les formulaires Web et vous navez pas le temps de les mettre à jour sur MVC, le code qui sera produit peut ne pas être de qualité. Apprendre les bases de MVC, puis sauter et faire cette page complexe que vous devez faire sont des choses très différentes. La courbe dapprentissage est élevée, vous devez donc en tenir compte dans votre budget.

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

Je ne dis pas que cest une approche tout ou rien ici, mais cela rend votre code plus difficile à maintenir sil y a une séparation des deux , surtout si tout le monde dans léquipe ne connaît pas MVC.

Mon entreprise a récemment réalisé trois pages de test avec MVC. Nous nous sommes assis et les avons conçues. Un problème que nous avons rencontré est que la plupart de nos écrans ont la fonctionnalité Afficher et Modifier sur la même page. Nous avons fini par avoir besoin de plus dun formulaire sur la page. Pas de biggy, sauf que nous nutiliserions pas notre page principale. Nous avons dû réorganiser cela afin que les pages Webforms 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 de nidification.

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

Javais limpression quil y avait trop de fichiers pour 3 pages, mais cest mon opinion personnelle.

À mon avis, vous choisiriez les formulaires Web plutôt que MVC si vous n’avez pas le temps / l’argent à investir dans la mise à jour de votre site pour utiliser MVC. Si vous faites une demi-approche à ce sujet, il ne sera pas meilleur 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 voir comme quelque chose d’inférieur à ce qu’elle connaît.

Commentaires

• Cest une bonne réponse. Je vous ai donné +1 parce que vos expériences personnelles sont appréciées. Mais cest un échec en raison dun manque dexpérience / de compétences des développeurs que jai demandé déviter . Je ne suis pas convaincu que Microsoft choisirait de ne pas marquer une technologie obsolète simplement par crainte de la courbe dapprentissage pour MVC. Cela peut être le cas, mais je ‘ ne suis pas encore convaincu.
• @ P.Brian.Mackey – Je nai ‘ pas dit que le développement de formulaires est plus rapide que MVC. Vous avez demandé de ne pas tenir compte de cet argument. Argumenter en termes de temps et dargent pour former votre personnel est un argument différent. MS a gagné ‘ t marquer les formulaires Web obsolètes pour une grande raison: les clients dentreprise ont passé des années à développer des clients Web dans des formulaires Web et ont gagné ‘ t semble gentil davoir à investir du temps et de largent pour mettre à jour.
• @Raynos – Si tous les membres de léquipe maîtrisaient MVC et que votre entreprise commençait un nouveau projet, la seule raison pour laquelle je pouvais voir quelquun choisir les formulaires Web était son choix personnel.
• Je connais intimement les deux technologies. Tous mes projets web sont réalisés avec mvc et travaillent dans une entreprise où jai libre cours pour faire la meilleure approche. Je choisis toujours MVC.
• Jai commencé avec Webforms et une fois que jai découvert MVC, je suis passé à cela. Je ‘ ne sais pas comment quiconque peut défendre les formulaires Web. Cycle de vie de la page et un formulaire pour la page entière? Vous plaisantez jespère? Yahoo sitebuilder était probablement le client prévu pour cela, mais même ils ne voulaient pas ‘ ce courrier indésirable.

Jai développé des applications ASP .Net WebForms pendant 3 ans, et après une journée de tutoriel MVC, jai été vendu. MVC est presque TOUJOURS la meilleure solution. Pourquoi?

• Le cycle de vie de la page est plus simple et plus efficace
• Il ny a pas de contrôles en dehors des contrôles html. Vous navez pas besoin de déboguer votre sortie pour voir ce que génère ASP .Net.
• ViewModels vous donne un pouvoir immense et évite la nécessité de faire une liaison de contrôle manuelle et élimine de nombreuses erreurs liées à la liaison.
• Vous pouvez avoir plusieurs formulaires sur une page. Il sagissait dune limitation sérieuse des WebForms.
• Le Web est sans état et MVC correspond plus étroitement à larchitecture du Web. Webforms présente létat et les bogues vous avez avec lui en introduisant le ViewState. Le ViewState est automatique et fonctionne en arrière-plan, donc il ne se comporte pas toujours comme vous le souhaitez.
• Les applications Web doivent fonctionner avec ajax ces jours-ci. Il nest plus acceptable davoir des chargements de page complète. MVC rend ajax tellement meilleur, plus facile et plus efficace avec JQuery.
• Parce que vous pouvez avoir plusieurs formulaires sur une page, et parce que larchitecture est piloté par des appels à des URL, vous pouvez faire des choses funky comme ajax charger un formulaire différent, comme un formulaire dédition dans votre page actuelle en utilisant JQuery. Une fois que vous réalisez ce que cela vous permet de faire, vous pouvez faire des choses incroyables facilement.
• ASP .Net WebForms nest pas seulement une abstraction sur html, cest une abstraction extrêmement complexe. Parfois, vous obteniez un bogue étrange et vous luttiez avec lui pendant beaucoup plus longtemps que nécessaire. Dans de nombreux cas, vous pouviez voir ce quil faisait mal mais vous ne pouvez rien y faire. Vous finissez par faire des solutions de contournement étranges.
• WebForms ne constitue pas une bonne technologie pour les concepteurs. Les concepteurs aiment souvent travailler directement avec HTML. Dans MVC, cest une vue, en WebForms, cest une demi-journée de travail.
• Alors que la plate-forme Web évolue rapidement, WebForms ne suivra pas. conscient des nouvelles balises ou fonctionnalités de HTML5, il restituera toujours les mêmes choses à moins que vous nobteniez (souvent) des contrôles tiers coûteux ou que vous attendiez que Microsoft publie une mise à jour.
• Les contrôles dans les formulaires Web vous limitent de bien des façons. Dans MVC, vous pouvez simplement récupérer une bibliothèque JQuery et lintégrer dans vos modèles.

Je sais que certains des problèmes ci-dessus ont été résolus dans une certaine mesure au fur et à mesure que WebForms évolue, mais cétait mon expérience originale. Dans lensemble, je trouverais extrêmement difficile de trouver une analyse de rentabilisation pour WebForms à moins quun projet ne lutilise déjà.

Commentaires

• +1 pour soulignant plusieurs formes. De plus, le fait que les formulaires Web HTML générés ne soient la plupart du temps pas très conviviaux pour le référencement (comme dans: de grandes parties de létat de vue en haut de la page)
• Je suis daccord à 100% avec cette réponse. En fin de compte, WebForms rend les choses beaucoup plus difficiles côté client (html / navigateur). Vous devez littéralement combattre le cadre pour faire quelque chose. Une page aspx se termine avec tellement plus de code en raison des contrôles du serveur quune page cshtml ne le fait généralement. @ šljaker Si vous commencez à désactiver ViewState et à éviter les contrôles serveur, vous ‘ avez abandonné une grande partie des WebForms à ce stade. Je ne ‘ pas voir cet argument comme particulièrement convaincant.
• Vous pouvez avoir des contrôles html simples dans WebForms, personne ne vous oblige à utiliser les contrôles serveur. Vous pouvez avoir un Webform sans état complet, personne ne vous oblige à utiliser ViewState. Vous pouvez utiliser ajax et jQuery complets dans les formulaires Web, personne ne vous empêche dutiliser jQuery. Vous pouvez implémenter le routage dURL, personne ne vous oblige à utiliser lURL de base du fichier statique. Dessiner manuellement une page avec CSS prend autant de temps que MVC en avait besoin. Vous pouvez concevoir une page HTML directement sur Webform.
• @mjb: Si vous ‘ nutilisez pas les contrôles serveur, ViewState, etc., pourquoi utiliser WebForms quand MVC est plus proche de ce que vous ‘ faites? Cela ‘ est comme conduire un tracteur au travail mais ne pas faire de tout-terrain ou utiliser la pelle / houe ou les barres stabilisatrices. À ce stade, pourquoi ne pas simplement utiliser une voiture?
• @Tjaart Il nest pas tout à fait normal que vous ne puissiez pas avoir plusieurs formulaires sur la page ASPNET.Vous pouvez avoir autant de formulaires que vous le souhaitez dans la page ASPNET, mais vous ne pouvez avoir quun seul formulaire serveur – formulaire avec runat =  » server  » attribut.

Jai envoyé un e-mail à Scott Guthrie , un expert MVC chez Microsoft. Et probablement lhomme le plus qualifié pour répondre à cette question. Il a eu la gentillesse de répondre:

« Différents clients recherchent différentes approches de programmation, et beaucoup aiment WebForms et pensent que cest génial. Dautres aiment MVC et Je pense que cest génial. Cest pourquoi nous investissons dans les deux. « 

Donc, pour moi, cela signifie que ce nest pas un problème technique. Cest plus une « question douce », si vous voulez. Un de préférence personnelle. Cela correspond à ce que plusieurs d’entre vous ont dit.

Merci pour toutes les réponses.

Commentaires

• Scott Guthrie a inventé le framework MVC pour ASP.NET lors dun vol de retour de Londres à Seattle en 2006/7. En y réfléchissant bien, il a aussi pratiquement inventé .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). Lappeler un  » expert  » est un énorme euphémisme 😉
• Que ‘ est une belle réponse politique de Scott Guthrie. Sil investissait lui-même sa propre application Web, vous ‘ verriez un projet MVC et pour tout ce qui ne pourrait ‘ t être fait dans MVC, Silverlight serait la solution de secours. Ne ‘ pas prendre cela comme un commentaire négatif envers WebForms, je pense que les WebForms sont parfaits pour les applications internes de plus petite envergure qui peuvent bénéficier de composants tiers tels que ceux créés par Telerik. Je ‘ je suis heureux que Microsoft progresse avec les deux technologies.
•  » Scott Guthrie a inventé le framework MVC pour ASP .NET pendant un vol  » Je pense que cela banalise vraiment MVC. Je ne ‘ ne connais pas Scott Guthrie, mais je ‘ parier quil avait demandé comment MVC pourrait être implémenté dans ASP.NET pendant un certain temps, et a utilisé ce long vol pour implémenter un prototype simple comme preuve de concept.
•  » Cest pourquoi nous investissons dans les deux.  » Et lorsque nous verrons que les formulaires Web commencent à décliner, nous labandonnerons sans pitié, car investir dans un produit finalement mort nest pas dans notre meilleur intérêt commercial.
• Jusquà il nest plus enseigné dans les écoles, pendant de nombreuses années, il sera toujours applicable dans le monde des affaires. Les collèges et lycées continuent doffrir des cours dintroduction et de perfectionnement sur vb.net. Il ne va nulle part !!!

Cest une question obsolète avec beaucoup de réponses mais aucune avait la réponse à laquelle je mattendais à figurer.

La réponse courte est:

• Utilisez ASP.NET MVC si vous avez lintention de créer correctement une application Web avec une programmation moderne conventions et modèles adoptés par lindustrie pour la plate-forme ASP.NET. En revanche, vous devrez savoir comment fonctionnent le HTML et les ressources côté client (Javascript, CSS), ainsi que progresser dans létat desprit de programmation MVC qui a une courbe dapprentissage abrupte mais atteint une fin soudaine une fois compris.
• Utilisez ASP.NET Web Forms si vous « utilisez ou souhaitez utiliser une GUI centrée, RAD (Rapid Application Development) , approche glisser-déposer pour prototyper quelque chose très rapidement, cest-à-dire comportement du bouton-poussoir / grille de données câblé en 15 minutes, et la solution nest pas conçue pour être prise en charge par Ou, Utilisez ASP.NET Web Forms si vous avez une expérience dans GUI ou le développement de Windows Forms et que vous souhaitez transférer votre connaissances sur le Web.

Mais pour bien regarder cela, vous devez comprendre lhistorique de chacun.

ASP.NET Web Forms était la réponse de Microsoft à ceux qui avaient créé des applications Web dynamiques à laide de Visual Basic 6 Ac contrôles tiveX, DLL VB6 sur le serveur et ASP Classic. À lépoque, le développement Web à laide de ces outils Microsoft était un véritable gâchis. En plus de lintégralité du .NET Framework, qui était le résultat de Microsoft revenant essentiellement à la planche à dessin sur la façon de faire de la programmation commerciale productive sur la pile Windows, ASP.NET Web Forms était, à son époque, incroyable et beau.

Lapproche globale était de donner aux développeurs le meilleur des deux mondes de quelque chose de très similaire au développement dapplications Windows, mais avec la puissance des services Internet.Lidée était que, tout comme avec un « Form » VB6 / WinForms (une fenêtre) de même une page Web est un formulaire (tout comme une fenêtre, voir) , et sur ce formulaire, vous pouvez faire glisser et déposer des étiquettes, des zones de texte, des grilles de données, des boutons et dautres choses auxquelles les développeurs de linterface graphique VB / WinForms étaient habitués.

Pour faire faire quelque chose à un bouton, après lavoir glissé-déposé, il vous suffit de double-cliquer dessus dans le concepteur et vous êtes dans léditeur de code, indiquant au formulaire ce quil faut faire lorsque « cliquez » « lévénement se produit. Cest exactement ainsi que les développeurs de linterface graphique Windows ont créé des logiciels à laide des outils GUI de VB6 et des outils concurrents, sauf que maintenant le code est en cours dexécution sur le serveur! Wow!

Cétait la technologie de 2002. Incroyable et beau en son temps comme réponse à Internet -enabled GUI solutions pour le développement de RAD , cela a apporté un sentiment de puissance à un monde désordonné de développeurs de logiciels qui avaient des objectifs commerciaux à atteindre.

Malheureusement, ce modèle de programmation met tellement laccent sur la métaphore de la programmation de linterface graphique Windows quil porte avec lui le fardeau de ses détails dimplémentation nécessaires , tous les bagages encombrants nca essentiel pour sadapter aux cycles de vie des événements et à la dissimulation des détails laids du HTML et du script simples que ces composants et contrôles glisser-déposer produiraient. Et à la fin de la journée, les développeurs prenant en charge de vraies applications devaient inévitablement creuser profondément dans ces composants ou écrire les leurs, et par conséquent, ils mèneraient des batailles avec cette infrastructure, des batailles qui laisseraient derrière eux des tas de tas de déchets, des cheveux tirés, et des larmes.

Recule. Lavez-vous les mains. Regardons à nouveau le problème commercial. 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 métier, des bases de données et une petite poignée dexcellents langages de programmation (par exemple C #). Avons-nous vraiment besoin de cette métaphore de linterface graphique Windows pour conduire notre méthodologie de développement? Pourquoi ne pouvons-nous pas nous concentrer uniquement sur les problèmes dapplication et supprimer les métaphores de linterface graphique?

Cest ici quASP.NET MVC entre en jeu. Il a commencé par une rébellion de développeurs qui se faisaient appeler « Alt.Net » qui voulaient revenir aux principes de développement logiciel appropriés et purs. Plus de soucis et de complications, concentrez-vous simplement sur les objectifs commerciaux et les meilleures pratiques logicielles.

Ce que cela signifie vraiment dans ce cas est:

1. Séparation des préoccupations . Par exemple, un composant de données na pas besoin de savoir comment ses données vont être rendues, ni le balisage de vue ne doit être encombré de détails de configuration de connexion à la base de données, et de cette manière un développeur peut se concentrer sur son domaine de préoccupation lors de lédition et code de test.
2. Exposition et prise en charge complète de l’exposition à l’essentiel du HTML et des ressources associées . Dans les formulaires Web, le HTML est caché, les développeurs sont découragés de sen occuper. Dans ASP.NET MVC, les développeurs sont plutôt encouragés à gérer ces détails; en fait, cest une nécessité. Lavantage ici est que le développeur peut réapprendre à apprécier la sémantique propre du HTML, du CSS et du script, et travailler avec plutôt que contre lui.
3. Testabilité des objets métier . Les contrôleurs et les modèles sont bien mieux adaptés aux tests unitaires programmatiques, de sorte que les implémentations peuvent être validées pour répondre aux objectifs commerciaux et que les modifications peuvent être vérifiées pour ne pas être interrompues. Avec les formulaires Web, il était difficile de tester car les composants nétaient pas conçus pour être testés individuellement et lensemble de la sortie de développement tournait autour des formulaires de page et de leurs cycles de vie des événements avec la boue de la logique métier et de la logique de présentation profondément imbriquée.

Notez que HTML est déjà un langage de balisage de très haut niveau, tout comme Javascript est un langage de programmation de haut niveau. Toute lhistoire aurait été différente si nous avions traité du langage dassemblage et du C.

En développant le n ° 2, un autre objectif dASP.NET MVC est de permettre aux développeurs dorganiser les détails frontaux de la partie «vue» de leurs solutions et tirer parti de la riche base que le reste de lindustrie a bâtie sur 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 battre avec larchitecture côté serveur. Ce nétait pas le cas à lorigine avec ASP.NET Web Forms, parce que Web Forms ne veut pas du tout que vous regardiez le HTML ou le script, sauf si vous devez vraiment , auquel cas attention, ce nest pas pour les âmes sensibles .

Commentaires

• Cest une bonne réponse, mais les # 1 et # 2 sont faux (WF na pas besoin dun composant pour savoir où ses données vient de, cest une option et vous avez toujours ajouté du HTML à vos fichiers ASPX pour prendre en charge les balises asp que vous affichez. Vous navez jamais eu besoin de creuser profondément et de combattre les contrôles à moins que vous nessayiez daccéder à une fonctionnalité ASP non destinée aux développeurs interaction. Les principaux points sont la testabilité et le modèle de conception.)

Je suis un converti complet et total à ASP.NET MVC et je nai pas regardé en arrière, cela dit que je dois encore maintenir plusieurs très grandes applications WebForms. Voici mon point de vue:

WebForms
Utilisez-les lorsque vous avez une vie sérieuse à voir avec les grilles. Les contrôles de grille sont vraiment très agréables lorsque vous avez un jeu de données simple qui sintègre bien 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 a un élément de type liste Ajax vraiment élégant que vous pouvez utiliser et qui fonctionne très bien, mais dans notre entreprise, nous avons souvent besoin de faire fonctionner quelque chose hier et de bonnes grilles à lancienne fonctionnent très bien et les utilisateurs sont heureux dêtre capable de naviguer sur une grille avec joie. Pour moi, cest vraiment la meilleure chose à propos de WebForms pour moi; mais, comme Ryan la souligné, WebForms peut être un gros gâchis parce que vous « jouez des deux côtés de la clôture à partir dun fichier code-behind astucieux. Cela peut être à la fois une rose et une épine pour garder tous vos éléments de type contrôleur mélangés à votre ou vos vues.

MVC
Utilisez ceci 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 est un peu plus de travail pour commencer, mais ses avantages en termes de maintenabilité lemportent sur le coût de configuration initial. Si vous voulez faire des interactions Ajax intéressantes, préférez écrire votre modèle avec du code, comme des URL et des routes propres, et être en mesure de contrôler tout le flux de votre application, alors cest certainement la voie à suivre. Il faut un certain temps pour sy habituer au début, mais je pense que c « est la meilleure option pour les applications greenfield.

En conclusion, pour moi, cela se résume aux grilles et! grilles. 🙂

Commentaires

• +1 pour la belle image livrée avec  » jouant des deux côtés du clôture à partir dun fichier code-behind astucieux « .
• Très utile celui-ci. Je ‘ m en train de faire une application très lourde basée sur la grille et jai ‘ exclu silverlight, xbap et cétait à un spectacle entre ces deux.

Mon expérience:

• Jai écrit des projets CakePHP pendant un an.
• A terminé un projet Webforms de taille moyenne sur six mois.
• Jai travaillé sur un projet Windows Forms pendant trois ans.

Après cette expérience, jai essayé décrire une autre application en utilisant des formulaires Web, et jai été frustré après avoir lutté pendant environ une journée avec la façon dont les formulaires Web tentent de protéger le développeur de la réalité quil « développe une application qui utilise html, javascript et css.

Jai ensuite essayé MVC, et ayant un contrôle plus direct sur la sortie (et une certaine expérience avec le paradigme MVC de CakePHP), jai pu compléter cette application simple exactement comme je le voulais en environ 1/2 journée.

La disponibilité de puissants frameworks dinterface utilisateur comme jQuery très bien eli minimise lattrait de renoncer au contrôle direct de la sortie au profit de lutilisation de composants dinterface utilisateur pré-construits souvent volumineux.

Commentaires

• @JimG – Euh , tout ce qui implique quune personne entre des enregistrements sans associations intéressantes dans une base de données, et que cette personne ou quelquun dautre les lise / les imprime à un autre moment peut être fondamentalement échafaudé à laide dun framework MVC. Certes, ce n’est ‘ que la plupart des applications, mais ‘ est bien plus que ce que vous pouvez faire avec Forms. Je suppose que votre -1 prouve mon point de vue.
• Que ‘ est 1/4 de jour.
• Mais si les besoins sélèvent à  » Jai besoin dune application avec deux rôles, lun pour enregistrer des informations, lautre pour les consulter, et je ne ‘ vraiment attention à ce à quoi il ressemble.  » Ensuite, oui, ce ‘ est tout à fait faisable.
• Je suis désolé, mais Le développement dune application Webforms pour saisir des données et afficher des données est si simple que cela peut être fait en quelques heures. la création de la structure dune application MVC, des contrôleurs, des vues et des actions prendrait le même temps, mais ne vous mènerait pas à un produit fini.
• @Dementic Habituellement, pour une application MVC simple, on construit des modèles, puis on élabore des contrôleurs et des vues et / ou génère des contrôleurs / vues échafaudés. Rien de vraiment chronophage ici.

Je préfère les formulaires Web parce que mon expérience est le développement Windows.

La vitesse de développement est un problème clé, et je peux facilement transmettre un problème à quelquun en Inde pour quil le répare du jour au lendemain avec des formulaires, aussi, si jai un problème de vitesse sur une page, un très bon livre sur asp.net la vitesse est pratique (Rick Kiessig est lhomme).

webforms est pour les personnes ex windows mvc est pour les internautes

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 lavantage

Mes 2 cents sont pour toujours utiliser ASP.NET MVC pour les nouveaux projets si vous en avez loption. À mon avis, les formulaires Web ne sont pas un bon moyen de développer des applications Web, point final.

Je pense que labstraction de REST de base est mauvaise, tout le modèle de publication est mauvais, la façon dont html / css est transmis avec confiance sur léditeur GUI est mauvais, laccent mis sur des éléments comme les assistants et les interfaces graphiques pour configurer des choses est mauvais, les URL sont mauvaises.

Commentaires

• pourriez-vous expliquer plus en détail pourquoi vous le pensez?
• Je pense que labstraction de REST de base est de retour, tout le modèle de publication est de retour, la façon dont html / css est transmis avec une dépendance à léditeur GUI est mauvaise , laccent mis sur des éléments tels que les assistants et les interfaces graphiques pour configurer des éléments est mauvais, les URL sont mauvaises, etc.

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

Il y a 3 à 4 ans, jai développé 2 ou 3 projets de site Web en utilisant Webforms. À cette époque, MVC nétait pas là ou je nen ai pas entendu parler. Le développement a été naturellement (je venais du développement Win-Forms sans expérience préalable en développement Web) rapide pour moi, car je nai pas besoin dapprendre le HTML dans les détails et les contrôles Web ont beaucoup aidé (beaucoup, cela a rendu la vie plus facile) .

Maintenant, après tout ce temps, je ne travaillais sur aucun projet Web jusquà récemment et je construisais simplement une application Windows en utilisant WPF.

Il y a quelques jours, javais une idée pour un et jai pensé à le développer: cette fois-ci en MVC (car on en parle partout, en plus javais besoin dapprendre non plus, alors je choisis MVC). Le projet est encore en phase de développement, puisque japprends et construis encore ensemble.

Donc, les différences clés que je trouve entre les deux sont les suivantes: –

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

• Pour quelquun venant du développement Web dans une autre technologie, MVC sera favorisé car il se moque du La dernière de toutes.

• Le développement est plus facile et plus propre dans MVC si vous êtes équipé de bonnes connaissances en HTML et CSS

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

En bref, les deux resteront ici pendant un certain temps.

Je « nai pas encore vu cette considération mise en avant parmi les 15 réponses existantes à ce fil de discussion, mais je le pense « Cela vaut la peine dêtre pris en compte.

Daprès mon expérience, Web Forms est plus similaire à Win Forms et WPF quà MVC. Compte tenu de cela, je pense que lon pourrait envisager de choisir Web Forms lorsque léquipe a le plus dexpérience dans ce type de technologie, ou lorsque le projet Web Forms fournira une interface sur le même ensemble de données quun Win Forms existant (ou développé simultanément) ou Projet WPF. Cela permet aux développeurs de passer plus facilement dun projet à lautre, car la logique dapplication peut être assez similaire entre les deux.

Comme dautres réponses lont souligné, le développement sur le framework MVC est plus similaire au développement Web dans Ruby, PHP, Python, etc. que ses homologues Microsoft; donc naturellement le choix du MVC peut être influencé par lexpérience des équipes dans ces domaines, ainsi que par les facteurs soumis dans dautres réponses.

Commentaires

• + 1 Certainement un argument raisonnable pour Webforms. Ma crainte est que les équipes suivent cet état desprit pour éviter dapprendre de nouvelles choses. MVC est rempli de nombreux modèles qui peuvent ne pas être familiers à une équipe. Lapprentissage de ces types de modèles et leur mise en œuvre conduit à une meilleure adhésion aux principes SOLID qui se traduit par une meilleure maintenabilité globale. Ces techniques éprouvées sont également la véritable clé de la réutilisation.

Notre raison de ne pas y aller à MVC il y a quelques années était une technologie immature de Microsoft. Au cours des dernières années, nous sommes maintenant sur une version plus mature (4) et MS semble avoir déterminé où ils vont avec cela.Cependant, nous hésitons toujours à développer des applications LOB majeures à laide de MVC car les fonctionnalités que nous souhaitons utiliser dans la version 4 nécessitent un serveur Windows 2012 (sur les sockets Web via IIS8). Je pense que dans un an de plus, nous accepterons davantage MVC car, espérons-le, davantage de contrôles tiers seront disponibles, la technologie se sera installée et nous aurons linfrastructure pour la prendre en charge.

Commentaires

• Pourriez-vous énumérer certaines de ces fonctionnalités qui, selon vous, nécessitent Windows Server 2012?

Cette décision dépend de vos préférences, de vos besoins ou même de vos connaissances et de votre expérience.

Le temps de la formation à lapprentissage MVC ou le temps de recevoir une livraison. Toutes ces choses comptent pour choisir lune ou lautre approche.

Nest-ce pas que lune est meilleure quune autre, simplement lapproche ou les frameworks ont des avantages et des inconvénients.

Personnellement, je préfère MVC 3, Je vous recommande dessayer davoir votre propre expérience, mais je dois dire que le 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 avez beaucoup plus de contrôles dinterface utilisateur tiers pour WebForms que MVC. Jai choisi MVC parce que jai trop travaillé avec WebForms et que je veux travailler avec quelque chose de frais / nouveau, mais toujours de la boutique MS 🙂

En gros, rien ne vous empêche de désactiver la vue dans WebForms et dutiliser ViewModels et des boucles if / for au lieu de la liaison de modèle et des contrôles côté serveur.

Sagit-il du code WebForms ou MVC:

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

La seule limitation que jai trouvée dans WebForms est que si vous utilisez Dependency Injection / Inversion of Contrôle, vous ne pouvez pas avoir dinjection de constructeur car les pages WebForms doivent avoir un constructeur sans paramètre, vous devez donc utiliser linjection de propriété. Est-ce vraiment un si gros problème?

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

ASP.NET Webforms vous donne beaucoup de contrôle sur le client du côté serveur, avec un accès direct à presque tout. Essentiellement, votre vue et votre contrôleur sont identiques, ce qui vous donne beaucoup de puissance, et la plupart du temps beaucoup de désordre.

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

Essentiellement, la différence est davoir beaucoup plus (généralement la totalité) du traitement pour afficher les données au fichier de vue, et en laissant la logique métier et le reste dans le contrôleur, en les gardant tous les deux plus propres par convention, mais aussi avec moins daccès les uns aux autres que ne le permet les formulaires Web.

Commentaires

• Alors QUAND faut-il privilégier les formulaires Web par rapport à MVC? Cela ne répond pas à la question dorigine des affiches.
• @WeekendWarrior – Si vous voulez plus daccès côté serveur au client, choisissez les formulaires Web. Si vous souhaitez plus de découplage client / serveur dans votre code, choisissez MVC. En fin de compte, ils font tous les deux exactement la même chose. Les filtres de réacheminement font la même chose que les URL MVC et vous pouvez déplacer le code des formulaires Web vers un niveau intermédiaire distinct pour le découpler davantage. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Concernant votre troisième point, cette logique métier se retrouve dans le fichier .aspx.cs – je pense que cest la faute des développeurs. Il ‘ nest pas / supposé / être là. Dans Webforms, le .aspx est la  » vue « , le .aspx.cs est le  » controller  » équivalent, destiné à traiter le code qui ne concerne directement que linterface utilisateur en interrogeant une couche métier ou une couche de façade métier à gros grains. Le fait que les gens mettent la logique métier dans le .aspx.cs est juste une mauvaise programmation. Ils pourraient également mettre la logique métier dans la vue dans MVC! MVC ne force pas ‘ t la séparation de ces choses.
• Essentiellement, il a plus raison que les autres réponses publiées ici. ASP.net est lidée de base dune famille de technologies Web modulaires créée par Microsoft. Le module ASP.net MVC peut être un battage médiatique temporel, mais ce nest certainement pas le dernier, tout commence par ASP.net, alors quand choisir ASP.net, si vous ne pensez pas que MVC nest pas votre truc, peut-être que vous préférez quelque chose else OWIN ou …, quelque chose de plus avancé, ou créez votre propre cadre pour vos tâches. Vous naurez peut-être même pas besoin dASP.MVC et sautez-le et passez à Owin ou Katana, mais jusquà ce que vous y utilisiez asp.net

À mon avis, ils sont assez liés et ont à peu près les mêmes capacités que cela devrait venir par préférence.

Un grand développeur WebForms peut produire un produit aussi puissant quun grand développeur MVC. Mais le grand développeur WebForms essayant de se forcer à adopter MVC va manquer. Il en va de même pour un grand développeur MVC qui donne une chance à WebForms.

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

Tout est question de choix personnel, en supposant que nous maîtrisions tous la technologie que nous utilisons. Jutilise lapproche de conception WebForms depuis de nombreuses années, et je dois dire que le seul inconvénient est quen raison de son approche simpliste, de nombreuses personnes ne prennent pas leur temps pour découvrir ses vastes capacités.

Jai récemment utilisé MVC pour terminer un projet, et même si jaime assez lapproche de conception du développement dapplications (qui vous donne plus de contrôle, des URL propres, du SOC, etc.), il ny a vraiment pas grand-chose à offrir , que les WebForms peuvent « t. 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 dun avantage que MVC a sur MVP, je leur demande combien ils connaissent la programmation orientée objet et à quel point ils mettent en œuvre le principe de labstraction et du polymorphisme.

Je suis actuellement à laise avec les deux technologies et je choisis en fonction de la situation. Franchement, cest terminé pour vous, 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.

Commentaires

• Idem on les vastes capacités des formulaires Web. La plupart des gens voient les rouages dentraînement des formulaires Web et les comparent avec MVC.
• Il ny a guère de sens à apprendre une abstraction au-dessus du HTML et du Javascript de nos jours (même en 2013). Cela ‘ ne vous servira à rien pour vos futures opportunités. HTML et Javas cript est très bien tel quil est. Le combattre est une bataille perdue.

Face à un problème de programmation, je me tourne souvent vers le Web pour les réponses. Webforms a des tonnes dinformations / composants sur quoi que ce soit. Dans MVC, en raison du moins grand nombre de sources en ligne et des couches dabstractions nécessaires pour faire fonctionner quelque chose, cela a limité les choses que je pouvais faire une fois. MVC total tue ma productivité en tant que développeur alors quavec les formulaires Web, cela ne lest pas. Donc, pour linstant, je men tiens aux formulaires Web jusquà ce que MVC ait suffisamment mûri pour le remplacer.

Eh bien, les WebForms ont plus de ressources dapprentissage disponibles (simplement parce quil est plus ancien) et donc les nouveaux programmeurs qui ne sont pas « t » au courant « seront plus susceptibles de trouver des informations concernant cette technologie plus ancienne par opposition aux nouveautés comme MVC.

Les programmeurs seniors / expérimentés sont plus âgés et maîtriseront mieux lancienne technologie car ils y ont programmé plus longtemps quils ont dans le plus récent.

À moins que vous ne puissiez dépenser de largent et des efforts pour que vos gars soient aussi compétents en MVC quils le sont dans les applications WebForms, vous allez sans aucun doute essayer de retarder la mise à niveau vers le nouveau plate-forme aussi longtemps que possible.

Cela pose donc plusieurs problèmes logistiques: les avantages du MVC lemportent-ils sur le coût en termes de qualité moindre et temps de déploiement? Si jai un site entièrement écrit en WebForms, cela vaudrait-il la peine et largent pour y intégrer MVC?

Comme indiqué par un précédent commentateur, MVC vous empêche également datteindre le même niveau dinterface avec le contrôleur comme vous le pourriez avec WebForms. Bien que je sois tout à fait pour le côté « Empêcher lutilisateur de bourrer les choses / dapprendre », il peut toujours être déraisonnablement gênant pour les équipes de déployer / mettre en œuvre un programme qui sen tient fanatiquement à ce paradigme pour tout ce quelles écrivent.

Je pense que l’écart entre ces deux technologies n’est plus aussi large qu’auparavant.

• 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 dun CDN et même retarder le chargement des scripts.

Pour répondre directement à votre question, je pense que cest une question de préférence et / ou quel est le projet. Ils adoptent tous deux une approche du développement très différente. Personnellement, jai travaillé sur le passage à MVC, mais jaime toujours travailler avec Webforms. Je pense que la réponse pour savoir si vous devriez utiliser MVC ou Webforms est à vous de décider en expérimentant les deux technologies.

Commentaires

• Webforms et MVC recommandent une attitude de développement Web radicalement différente par défaut, cest important , peu de développeurs sécartent à partir de  » la valeur par défaut « . Cependant, les deux peuvent être utilisés pour réaliser la même chose.