Quand privilégier ASP.NET WebForms sur MVC


189

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?


57
@Darknight: \ c'est très partial et tout simplement faux. MVC n'est pas pour les simples applications CRUD. Je dirais que WebForms est destiné aux applications CRUD génériques (base de données -> un contrôle de grille brillant).
Raynos

17
@Darknight tout ce qui vous rend heureux -> si vous aimez WebForm, allez-y en fou;)
Raynos

16
@Darknight Vous avez évidemment une mauvaise compréhension de MVC, si tel est votre avis ... Il existe de très gros sites construits avec mvc ... faites des recherches, monsieur.
Robotsushi

31
Messieurs, n'utilisez jamais de formulaires Web lorsque vous pouvez utiliser MVC à la place.
scottschulthess

10
Je ne suis pas du genre à parler, ce n'est donc que mon opinion. Après avoir lu la plupart des réponses, j'en suis venu à la conclusion que la réponse est tout simplement jamais. MVC est tout simplement génial et le seul inconvénient que j'ai trouvé est que je continue à le voir ;sur ma page Web (si vous commencez juste avec Razor, vous aurez la blague).
MasterMastic

Réponses:


105

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.


14
C'est une bonne réponse. Je vous ai donné +1 parce que vos expériences personnelles sont appréciées. Mais c’est un échec dû à un manque d’expérience / de compétences des développeurs que j’ai demandé à éviter. Je ne suis pas convaincu que Microsoft choisirait de ne pas marquer une technologie obsolète simplement par crainte de la courbe d'apprentissage de MVC. C'est peut-être le cas, mais je ne suis pas encore convaincu.
P.Brian.Mackey

6
@ P.Brian.Mackey - Je n'ai pas dit que le développement de formulaires est plus rapide que MVC. Vous avez demandé de laisser cet argument en dehors de cela. Réclamer du temps et de l'argent pour former votre personnel est un argument différent. MS ne veut pas dire que les formulaires Web sont obsolètes pour une raison importante: les clients d'entreprise ont passé des années à développer des clients Web dans des formulaires Web et ne semblent pas avoir besoin d'investir temps et argent pour la mise à jour.
Tyanna

16
@Raynos - Si tous les membres de l'équipe connaissaient bien MVC et que votre entreprise commençait un nouveau projet, la seule raison pour laquelle je pouvais voir quelqu'un choisir des formulaires Web était un choix personnel.
Tyanna

3
Je connais les deux technologies intimement. Tous mes projets Web sont réalisés avec mvc et travaillent dans une entreprise où je suis libre de faire ce qui convient le mieux. Je choisis toujours MVC.
Robotsushi

6
J'ai commencé avec Webforms et une fois que j'ai découvert MVC, je suis passé à cela. Je ne sais pas comment quiconque pourrait défendre les formulaires Web. Cycle de vie d'une page et un formulaire pour la page entière? Vous plaisantez j'espère? Le constructeur de site Yahoo était probablement le client visé, mais même ceux-ci ne voulaient pas de cette malbouffe.
Le Muffin Man

188

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à.


6
+1 pour signaler plusieurs formes. De plus, le fait que les formulaires Web HTML générés ne soient généralement pas très conviviaux pour le référencement (par exemple: gros morceaux de viewstate en haut de la page)
jao

4
Je suis d'accord à 100% avec cette réponse. À la fin de la journée, WebForm rend beaucoup plus difficile le travail côté client (html / browser). Vous devez littéralement combattre le cadre pour obtenir quelque chose de fait. Une page aspx se termine avec beaucoup plus de code en raison de contrôles de serveur qu'une page cshtml. @ šljaker Si vous commencez à désactiver ViewState et à éviter les contrôles serveur, vous avez abandonné une grande partie de WebForm à ce stade. Je ne vois pas cet argument comme particulièrement convaincant.
Andy

12
Vous pouvez avoir des contrôles HTML simples dans WebForms, personne ne vous oblige à utiliser les contrôles Serveur. Vous pouvez avoir un formulaire Web complet sans état, personne ne vous obligera à utiliser ViewState. Vous pouvez utiliser les méthodes ajax et jQuery complètes dans les formulaires Web, personne ne vous empêchant d'utiliser jQuery. Vous pouvez implémenter le routage d'URL, personne ne vous oblige à utiliser une URL de base de fichier statique. Dessiner manuellement une page avec CSS consomme le temps nécessaire à MVC. Vous pouvez concevoir une page HTML directement sur Webform.
Mjb

5
@ mjb: Si vous n'utilisez pas les contrôles serveur, ViewState, etc., pourquoi utiliser WebForms du tout lorsque MVC se rapproche de ce que vous faites? C'est comme conduire un tracteur au travail mais ne pas faire de route ou utiliser la pelle / houe ou les barres stabilisatrices. À ce stade, pourquoi ne pas simplement utiliser une voiture?
Nelson Rothermel

3
@Tjaart Il n'est pas correct de ne pas avoir plusieurs formulaires sur une page ASPNET. Vous pouvez avoir autant de formulaires que vous le souhaitez dans une page ASPNET, mais vous pouvez ne disposer que d’un formulaire de serveur avec attribut runat = "server".
Kuncevic

80

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.


12
Scott Guthrie a inventé le framework MVC pour ASP.NET lors d'un vol retour entre Londres et Seattle en 2006/7. À bien y penser, il a également inventé .NET également ( en.wikipedia.org/wiki/Scott_Guthrie ). Le qualifier d '"expert" est un énorme euphémisme ;-)
Benjamin Howarth

27
C'est une belle réponse politique de Scott Guthrie. S'il investissait lui-même sa propre application Web, vous verriez un projet MVC et, pour tout ce qui ne pourrait pas être fait dans MVC, Silverlight serait la solution de rechange. Ne considérez pas cela comme un commentaire négatif vis-à-vis de WebForms. Je pense que les WebForms sont parfaits pour les applications internes de moindre envergure pouvant tirer parti de composants tiers tels que ceux créés par Telerik. Je suis content que Microsoft aille de l'avant avec les deux technologies.
Sean Chase

10
"Scott Guthrie a inventé le framework MVC pour ASP.NET lors d’un vol" Je pense que cela rend vraiment MVC trivial. Je ne connais pas Scott Guthrie, mais je suis prêt à parier qu'il spéculait sur la façon dont MVC pourrait être implémenté dans ASP.NET depuis un moment et avait utilisé ce long vol pour implémenter un prototype à nu, comme preuve de concept.
John MacIntyre

6
"C'est pourquoi nous investissons dans les deux." Et lorsque nous verrons que les formulaires Web commencent à décliner, nous les abandonnerons sans merci, car investir dans un produit finalement mort ne sert pas notre meilleur intérêt commercial.
Quandary

Jusqu'à ce qu'il ne soit plus enseigné dans les écoles, pendant de nombreuses années, il sera toujours applicable dans le monde des affaires. Les collèges et les lycées continuent à proposer des cours d'introduction et de perfectionnement sur vb.net. Ce n'est pas aller n'importe où !!!
htm11h

44

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.


C'est une bonne réponse, mais les n ° 1 et n ° 2 sont incorrects (WF n'exige pas qu'un composant sache d'où proviennent ses données, c'est une option et vous avez toujours ajouté du code HTML à vos fichiers ASPX pour prendre en charge les balises asp que vous êtes. . le rendu vous avez jamais eu besoin de creuser profondément et combattre les contrôles , à moins que vous essayez d'accéder à une fonction ASP non destinés à l' interaction des développeurs les grands points sont testabilité et design pattern)..
Trisped

39

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. :)


+1 pour la belle image livrée avec "jouer des deux côtés de la clôture à partir d'un fichier code-behind astucieux".
Marcel

Très utile celui-ci. Je fais une application très lourde basée sur la grille et j'ai éliminé silverlight, xbap et il s'agissait d'un spectacle entre ces deux.
frostymarvelous

15

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.


2
@JimG - Euh, tout ce qui implique qu'une personne entre des enregistrements sans associations intéressantes dans une base de données et que cette personne ou quelqu'un d'autre les lise / lise à un autre moment peut être fondamentalement échafaudé à l'aide d'un framework MVC. Certes, ce n'est pas la plupart des applications, mais c'est bien plus que ce que vous pouvez faire avec Forms. Je suppose que votre -1 prouve mon point.
Mootinator

1
C'est 1/4 de jour.
Mootinator

1
Mais si les conditions requises sont les suivantes: "J'ai besoin d'une application avec deux rôles, l'un pour enregistrer certaines informations, l'autre pour l'examiner, et je ne me soucie pas vraiment de son apparence." Alors, oui, c'est tout à fait faisable.
Mootinator

3
Je suis désolé, mais développer une application de formulaires Web pour entrer des données et afficher des données est si simple qu'il peut être fait en quelques heures. La création de la structure d'une application MVC, Contrôleurs, Vues et Actions, prendrait le même temps, mais ne vous permettrait pas d'obtenir un produit fini.
Dementic

2
@Dementic Généralement, pour une application MVC simple, on construit des modèles, puis échafaudage des contrôleurs et des vues et / ou génère des contrôleurs / vues échafaudés. Rien ne prend vraiment beaucoup de temps là-bas.
Mootinator

8

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


7

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.


Pourriez-vous expliquer plus en détail pourquoi vous le pensez?
moucher le

Je pense que l’abstraction de REST de base est de retour, le modèle de postback complet est de retour, la façon dont html / css est utilisé avec une confiance dans l’éditeur d’interface graphique est mauvaise, l’accent est mis sur des éléments tels que des assistants et des interfaces sont mauvais, etc. et ainsi de suite
scottschulthess

6

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.


6

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.


+1 Certainement un argument raisonnable pour les formulaires Web. Ma crainte est que les équipes suivent cet état d'esprit pour éviter d'apprendre de nouvelles choses. MVC est rempli de nombreux modèles qui peuvent ne pas être familiers à une équipe. Apprendre ces types de motifs et les mettre en œuvre conduit à une meilleure adhésion aux principes SOLID, ce qui se traduit par une meilleure maintenabilité globale. Ces techniques éprouvées sont également la véritable clé de la réutilisation.
P.Brian.Mackey

3

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.


1
Souhaitez-vous énumérer certaines de ces fonctionnalités qui, selon vous, nécessitent Windows Server 2012?
MikeTeeVee

2

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,


2

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?


1

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.


Alors, quand les formulaires Web doivent-ils être préférés à MVC? Cela ne répond pas à la question des affiches originales.
Steven Striga

@WeekendWarrior - Si, si vous souhaitez davantage d'accès côté client au client, choisissez des formulaires Web. Si vous souhaitez davantage de découplage du client / serveur dans votre code, choisissez MVC. À la fin de la journée, ils font 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 de formulaires Web vers un niveau intermédiaire séparé pour le découpler davantage. weblogs.asp.net/scottgu/archive/2010/01/24/…
Ryan Hayes Le

En ce qui concerne votre troisième point, cette logique métier se retrouve dans le fichier .aspx.cs. Je pense que c'est la faute des développeurs. Ce n'est pas / supposé / être là. Dans Webforms, le .aspx est la "vue", le .aspx.cs est le "contrôleur", destiné à traiter le code directement lié à l'interface utilisateur en interrogeant une couche de gestion ou une couche de façade à grains grossiers. Le fait que les utilisateurs insèrent la logique métier dans le fichier .aspx.cs est simplement une mauvaise programmation. Ils pourraient également intégrer la logique métier dans la vue dans MVC! MVC ne force pas la séparation de ces choses.
James

Essentiellement, il a plus raison que les autres réponses publiées ici. ASP.net est l’idée de base d’une famille de technologies Web modulaires créée par Microsoft. Le module ASP.net MVC est peut-être un battage publicitaire temporaire, mais il est certain que ce n'est pas la dernière, tout commence par ASP.net. Quand choisir ASP.net, si vous ne pensez pas que MVC n'est pas votre truc, peut-être que vous êtes plus intéressé par quelque chose sinon OWIN ou ..., quelque chose de plus avancé, ou fait votre propre cadre pour vos tâches. Vous n’avez peut-être même pas besoin d’ASP.MVC et sautez-le et allez à Owin ou Katana, mais jusqu’à ce que vous
utilisiez celui

1

À 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.


0

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.


Idem sur les vastes capacités des formulaires Web. La plupart des gens voient les roues de formation des formulaires Web et comparent cela avec MVC.
TheLegendaryCopyCoder

Il est peu logique d’apprendre une abstraction au-dessus de HTML et de Javascript de nos jours (même en 2013). Cela ne vous fera aucun bien pour vos opportunités futures. HTML et Javascript sont bien comme ça. Le combattre est une bataille perdue d'avance.
user441521

0

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.


0

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.


-1

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.


1
Webforms et MVC recommandent une attitude de développement Web radicalement différente par défaut. Ceci est important , peu de développeurs s’écartent de "la valeur par défaut". Les deux peuvent cependant être utilisés pour atteindre le même objectif.
Raynos
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.