Wann ist ASP.NET WebForms gegenüber MVC vorzuziehen?

189

Ich weiß, dass Microsoft gesagt hat

ASP.NET MVC ist kein Ersatz für WebForms.

Und einige Entwickler sagen, WebForms sei schneller zu entwickeln als MVC. Aber ich glaube, die Geschwindigkeit der Codierung hängt vom Komfort der Technologie ab, daher möchte ich keine Antworten in diesem Sinne.

Warum gelten WebForms nicht als veraltet, da ASP.NET MVC Entwicklern mehr Kontrolle über ihre Anwendung gibt? Wann sollte ich für die Neuentwicklung WebForms gegenüber MVC bevorzugen?

user53019
quelle
57
@ Darknight: Das ist sehr voreingenommen und einfach falsch. MVC ist nicht für einfache CRUD-Apps geeignet. Ich würde behaupten, WebForms ist für generische CRUD-Apps (dh Datenbank -> einige glänzende Rastersteuerung).
Raynos
17
@ Darknight, was auch immer Sie glücklich macht -> wenn Sie WebForms mögen, werden Sie verrückt danach;)
Raynos
16
@ Darknight Sie haben offensichtlich ein schlechtes Verständnis von MVC, wenn dies Ihre Meinung ist ... Es gibt einige riesige Websites, die mit MVC erstellt wurden ... machen Sie einige Nachforschungen, Sir.
Robotsushi
31
IMO, verwenden Sie niemals Webformulare, wenn Sie stattdessen MVC verwenden können.
Scottschulthess
10
Ich bin kein Redner, das ist nur meine Meinung. Nachdem ich die meisten Antworten gelesen hatte, kam ich zu dem Schluss, dass die Antwort einfach nie ist. MVC ist einfach fantastisch und der einzige Nachteil, den ich gefunden habe, ist, dass ich immer wieder ;auf meiner Webseite nachschaue (wenn Sie gerade mit Razor anfangen, werden Sie den Witz verstehen).
MasterMastic

Antworten:

105

Webforms vs. MVC scheint gerade ein heißes Thema zu sein. Jeder, den ich kenne, wirbt dafür, dass MVC das nächste große Ding ist. Nach meinen geringfügigen Änderungen scheint es in Ordnung zu sein, aber nein, ich glaube nicht, dass Webformulare damit enden werden.

Meine Überlegungen und die Überlegungen, warum Webformulare gegenüber MVC ausgewählt werden, haben eher mit einer Geschäftsperspektive zu tun als mit dem, was besser ist als das andere.

Zeit / Geld sind die Hauptgründe, warum Webformulare gegenüber MVC ausgewählt werden.

Wenn der Großteil Ihres Teams Webformulare kennt und Sie nicht die Zeit haben, diese in MVC auf den neuesten Stand zu bringen, ist der Code, der erstellt wird, möglicherweise nicht von hoher Qualität. Das Erlernen der Grundlagen von MVC und das Ausführen der komplexen Seite, die Sie ausführen müssen, sind sehr unterschiedliche Dinge. Die Lernkurve ist hoch, sodass Sie dies in Ihr Budget einbeziehen müssen.

Wenn Sie eine große Website haben, die ausschließlich in Webforms geschrieben ist, sind Sie möglicherweise eher geneigt, neue Seiten in Webforms zu erstellen, damit Ihre Website keine zwei sehr unterschiedlichen Seitentypen enthält.

Ich sage hier nicht, dass es ein Alles-oder-Nichts-Ansatz ist, aber es erschwert die Pflege Ihres Codes, wenn es eine Trennung von beiden gibt, insbesondere wenn nicht alle im Team mit MVC vertraut sind.

Meine Firma hat kürzlich drei Testseiten mit MVC erstellt. Wir haben uns hingesetzt und sie entworfen. Ein Problem, auf das wir gestoßen sind, ist, dass die meisten unserer Bildschirme die Funktionen zum Anzeigen und Bearbeiten auf derselben Seite haben. Wir brauchten schließlich mehr als ein Formular auf der Seite. Kein Problem, außer dann würden wir unsere Masterseite nicht benutzen. Wir mussten dies überarbeiten, damit sowohl die Webforms-Seiten als auch die MVC-Seiten dieselbe Masterseite für ein einheitliches Erscheinungsbild verwenden konnten. Jetzt haben wir eine zusätzliche Verschachtelungsebene.

Wir mussten eine völlig neue Ordnerstruktur für diese Seiten erstellen, damit sie der ordnungsgemäßen MVC-Trennung entsprach.

Ich hatte das Gefühl, dass es zu viele Dateien für 3 Seiten gibt, aber das ist meine persönliche Meinung.

Meiner Meinung nach würden Sie sich für Webformulare gegenüber MVC entscheiden, wenn Sie nicht genug Zeit und Geld haben, um Ihre Website für die Verwendung von MVC zu aktualisieren. Wenn Sie dies nur halbherzig angehen, wird es nicht besser sein als die Webformulare, die Sie jetzt haben. Schlimmer noch, Sie könnten diese Technologie sogar für ein Versagen in Ihrem Unternehmen einrichten, wenn sie durcheinander ist, da das obere Management sie möglicherweise als etwas sieht, das dem, was sie wissen, unterlegen ist.

Tyanna
quelle
14
Das ist eine gute Antwort. Ich habe dir +1 gegeben, weil deine persönlichen Erfahrungen geschätzt werden. Dies ist jedoch ein Misserfolg aufgrund mangelnder Erfahrung / Fähigkeiten der Entwickler, die ich vermeiden wollte. Ich bin nicht davon überzeugt, dass Microsoft sich aus Angst vor der Lernkurve für MVC dafür entscheiden würde, eine Technologie nicht als veraltet zu markieren. Das mag der Fall sein, aber ich bin noch nicht überzeugt.
P. Brian Mackey
6
@ P.Brian.Mackey - Ich habe nicht gesagt, dass die Formularentwicklung schneller ist als MVC. Sie haben darum gebeten, dieses Argument wegzulassen. Das Argument, Zeit und Geld für die Schulung Ihrer Mitarbeiter einzusetzen, ist ein anderes. MS wird Webformulare aus einem wichtigen Grund nicht als veraltet markieren: Enterprise-Kunden haben jahrelang Web-Clients für Webformulare entwickelt und müssen zum Aktualisieren keine Zeit und Geld investieren.
Tyanna
16
@Raynos - Wenn jeder im Team MVC beherrschte und Ihr Unternehmen ein neues Projekt startete, war der einzige Grund, warum ich jemanden sehen konnte, der sich für Webforms entschied, die persönliche Entscheidung.
Tyanna
3
Ich kenne beide Technologien sehr gut. Alle meine Webprojekte werden mit mvc durchgeführt und arbeiten in einem Unternehmen, in dem ich die Freiheit habe, das zu tun, was der beste Ansatz ist. Ich wähle immer MVC.
Robotsushi
6
Ich begann mit Webforms und als ich MVC entdeckte, wechselte ich dazu. Ich weiß nicht, wie jemand Webformulare verteidigen könnte. Seitenlebenszyklus und ein Formular für die gesamte Seite? Willst du mich veräppeln? Yahoo Sitebuilder war wahrscheinlich der dafür vorgesehene Kunde, aber selbst sie wollten diesen Müll nicht.
The Muffin Man
188

Ich habe 3 Jahre lang ASP .Net WebForms-Anwendungen entwickelt und nach einem Tag MVC-Tutorial war ich verkauft. MVC ist fast IMMER die bessere Lösung. Warum?

  • Die Seitenlebensdauer ist einfacher und effizienter
  • Außer HTML-Steuerelementen gibt es keine weiteren Steuerelemente. Sie müssen Ihre Ausgabe nicht debuggen, um zu sehen, was ASP .Net generiert.
  • ViewModels bieten Ihnen immense Leistung und machen manuelle Steuerungsbindungen überflüssig. Außerdem werden viele Fehler im Zusammenhang mit der Bindung beseitigt.
  • Sie können mehrere Formulare auf einer Seite haben. Dies war eine schwerwiegende Einschränkung von WebForms.
  • Das Web ist zustandslos und MVC passt besser zur Architektur des Webs. Webforms führt den Status und die damit verbundenen Fehler ein, indem der ViewState eingeführt wird. Der ViewState ist automatisch und arbeitet im Hintergrund. Daher verhält er sich nicht immer so, wie Sie es möchten.
  • Webanwendungen müssen heutzutage mit Ajax arbeiten. Es ist nicht mehr akzeptabel, vollständige Seiten zu laden. MVC macht Ajax mit JQuery so viel besser, einfacher und effizienter.
  • Da eine Seite mehrere Formulare enthalten kann und die Architektur von Aufrufen von URLs bestimmt wird, können Sie kuriose Dinge wie das Laden eines anderen Formulars, z. B. eines Bearbeitungsformulars, mit JQuery in Ihre aktuelle Seite ausführen. Sobald Sie erkennen, was Sie damit tun können, können Sie auf einfache Weise erstaunliche Dinge tun.
  • ASP .Net WebForms ist nicht nur eine Abstraktion über HTML, sondern auch eine äußerst komplexe. Manchmal bekam man einen seltsamen Bug und kämpfte viel länger damit als nötig. In vielen Fällen konnte man tatsächlich sehen, was falsch gemacht wurde, aber Sie können nichts dagegen tun. Sie machen am Ende seltsame Workarounds.
  • WebForms ist keine gute Technologie für Designer. Designer arbeiten häufig gerne direkt mit HTML. In MVC ist es eine Ansicht, in WebForms ist es ein halber Arbeitstag.
  • Da sich die Webplattform schnell entwickelt, können WebForms nicht mithalten. Es sind keine neuen Tags oder Funktionen von HTML5 bekannt, es werden jedoch dieselben Inhalte gerendert, es sei denn, Sie erhalten (häufig) teure Steuerelemente von Drittanbietern oder warten, bis Microsoft ein Update herausgibt.
  • Steuerelemente in WebForms schränken Sie in vielerlei Hinsicht ein. In MVC können Sie einfach eine JQuery-Bibliothek abrufen und in Ihre Vorlagen integrieren.

Ich weiß, dass einige der oben genannten Probleme im Zuge der Entwicklung von WebForms teilweise behoben wurden, aber das war meine ursprüngliche Erfahrung. Alles in allem würde es mir sehr schwer fallen, einen Business Case für WebForms zu finden, es sei denn, ein Projekt verwendet ihn bereits.

Tjaart
quelle
6
+1 für das Hinweisen auf mehrere Formulare. Plus die Tatsache, dass die HTML-Webformulare generieren, ist die meiste Zeit nicht sehr SEO-freundlich (wie in: große Brocken von viewstate oben auf der Seite)
Jao
4
Ich muss dieser Antwort zu 100% zustimmen. Letztendlich ist es für WebForms viel schwieriger, Dinge auf der Client-Seite (HTML / Browser) zu erledigen. Man muss buchstäblich gegen die Rahmenbedingungen kämpfen, um etwas zu erledigen. Eine aspx-Seite hat aufgrund von Serversteuerelementen so viel mehr Code als eine cshtml-Seite normalerweise. @ šljaker Wenn Sie ViewState deaktivieren und Serversteuerungen vermeiden, haben Sie zu diesem Zeitpunkt viele WebForms aufgegeben. Ich halte dieses Argument nicht für besonders überzeugend.
Andy
12
In WebForms können Sie einfache HTML-Steuerelemente verwenden. Niemand zwingt Sie, Serversteuerelemente zu verwenden. Sie können über ein vollständiges zustandsloses Webformular verfügen, ohne dass Sie dazu gezwungen werden, ViewState zu verwenden. Sie können Ajax und jQuery vollständig in Webforms verwenden. Niemand hindert Sie daran, jQuery zu verwenden. Sie können das URL-Routing implementieren. Niemand erzwingt die Verwendung einer statischen Dateibasis-URL. Das manuelle Zeichnen einer Seite mit CSS nimmt so viel Zeit in Anspruch, wie MVC benötigt. Sie können HTML-Seiten direkt in Webform entwerfen.
mjb
5
@mjb: Wenn Sie keine Serversteuerelemente, ViewState usw. verwenden, warum sollten Sie überhaupt WebForms verwenden, wenn MVC näher an Ihren Aufgaben ist? Es ist so, als würde man einen Traktor zur Arbeit fahren, aber nicht im Gelände fahren oder die Schaufel / Hacke oder Stabilisatoren verwenden. Warum dann nicht einfach ein Auto benutzen?
Nelson Rothermel
3
@Tjaart Es ist nicht ganz richtig, dass Sie nicht mehrere Formulare auf der ASPNET-Seite haben können. Auf der ASPNET-Seite können beliebig viele Formulare vorhanden sein, es kann jedoch nur ein Serverformular vorhanden sein - Formular mit dem Attribut runat = "server".
Kuncevic
80

Ich schickte eine E-Mail an Scott Guthrie , einen MVC-Experten bei Microsoft. Und wahrscheinlich der qualifizierteste Mann, um diese Frage zu beantworten. Er war so freundlich zu antworten:

"Verschiedene Kunden suchen nach unterschiedlichen Programmieransätzen und lieben WebForms sehr und finden es großartig. Andere lieben MVC und finden es großartig. Deshalb investieren wir in beide."

Für mich ist das also kein technisches Problem. Es ist eher ein "soft issue", wenn man so will. Eine persönliche Vorliebe. Dies steht im Einklang mit dem, was mehrere von Ihnen gesagt haben.

Danke für alle Antworten.

P. Brian Mackey
quelle
12
Scott Guthrie erfand das MVC-Framework für ASP.NET auf einem Rückflug von London nach Seattle 2006/07. Wenn Sie sich das vorstellen, hat er auch .NET erfunden ( en.wikipedia.org/wiki/Scott_Guthrie ). Ihn einen "Experten" zu nennen ist eine enorme Untertreibung ;-)
Benjamin Howarth
27
Das ist eine nette politische Antwort von Scott Guthrie. Wenn er selbst seine eigene Webanwendung investieren würde, würden Sie ein MVC-Projekt sehen, und für alles, was in MVC nicht möglich wäre, wäre Silverlight der Fallback. Betrachten Sie dies nicht als einen Kommentar, der für WebForms negativ ist. Ich denke, WebForms eignen sich hervorragend für interne Anwendungen mit kleinerem Umfang, die von Komponenten von Drittanbietern wie den von Telerik erstellten profitieren können. Ich bin froh, dass Microsoft beide Technologien weiterentwickelt.
Sean Chase
10
"Scott Guthrie hat das MVC-Framework für ASP.NET während eines Fluges erfunden", denke ich, das macht MVC wirklich trivial. Ich kenne Scott Guthrie nicht, aber ich wette, er hatte eine Weile darüber nachgedacht, wie MVC in ASP.NET implementiert werden könnte, und diesen langen Flug genutzt, um einen Bare-Bones-Prototyp als Proof-of-Concept zu implementieren.
John MacIntyre
6
"Deshalb investieren wir in beides." Und wenn wir feststellen, dass die Anzahl der Webformulare abnimmt, lassen wir sie gnadenlos fallen, da die Investition in ein letztendlich totes Produkt nicht in unserem besten Geschäftsinteresse liegt.
Quandary
Bis es für viele Jahre nicht mehr in Schulen unterrichtet wird, wird es immer in der Geschäftswelt anwendbar sein. Hochschulen und Gymnasien bieten weiterhin Einführungs- und Fortgeschrittenenkurse in vb.net an. Es geht nirgendwo hin !!!
htm11h
44

Dies ist eine veraltete Frage mit vielen Antworten, aber keine hatte die Antwort, die ich erwartet hätte, aufgelistet zu werden.

Die kurze Antwort lautet:

  • Verwenden Sie ASP.NET MVC, wenn Sie eine Webanwendung mit modernen Programmierkonventionen und branchenüblichen Mustern für die ASP.NET-Plattform ordnungsgemäß erstellen möchten. Auf der anderen Seite wird erwartet, dass Sie wissen, wie HTML- und clientseitige Ressourcen (Javascript, CSS) funktionieren, und dass Sie die MVC-Programmiermentalität verbessern, die eine steile Lernkurve aufweist, aber ein plötzliches Ende erreicht, wenn sie erst einmal erfasst ist.
  • Verwenden Sie ASP.NET Web Forms, wenn Sie eine GUI-orientierte , RAD- basierte (Rapid Application Development) Drag-and-Drop- Methode verwenden möchten, um sehr schnell Prototypen zu erstellen, z 15 Minuten, und die Lösung soll nicht von den Entwicklern unterstützt werden. Oder Verwenden ASP.NET Web Forms , wenn Sie einen Hintergrund in der GUI oder Windows Forms - Entwicklung und Sie wünschen Wissen im Web zu übertragen.

Aber um dies richtig zu betrachten, muss man die Geschichte eines jeden verstehen.

ASP.NET Web Forms war die Antwort von Microsoft auf diejenigen, die dynamische Webanwendungen mit Visual Basic 6-ActiveX-Steuerelementen, VB6-DLLs auf dem Server und ASP Classic erstellt hatten. Zu dieser Zeit war die Webentwicklung mit diesen Microsoft-Tools ein echtes Chaos. Zusammen mit der Gesamtheit des .NET Frameworks, das die Ausgabe von Microsoft darstellte, die im Wesentlichen auf das Zeichenbrett zurückging, wie produktive Geschäftsprogramme auf dem Windows-Stapel erstellt werden, war ASP.NET Web Forms zu seiner Zeit erstaunlich und wunderschön.

Der gesamte Ansatz bestand darin, Entwicklern das Beste aus beiden Welten zu bieten, was der Entwicklung von Windows-Anwendungen sehr ähnlich ist, jedoch mit der Leistungsfähigkeit von Internetdiensten. Die Idee war, dass genau wie bei einem VB6 / WinForms "Formular" (ein Fenster) auch eine Webseite ein Formular ist (genau wie ein Fenster, siehe) , und auf diesem Formular können Sie Beschriftungen, Textfelder, Datenraster, Schaltflächen und andere Dinge, an die VB / WinForms-GUI-Entwickler gewöhnt waren.

Um eine Schaltfläche dazu zu bringen, etwas zu tun, doppelklicken Sie nach dem Ziehen und Ablegen im Designer darauf, und Sie befinden sich im Code-Editor. Hier erfahren Sie, was zu tun ist, wenn dieses "Klick" -Ereignis eintritt. Genau so haben Windows-GUI-Entwickler Software mit dem GUI- Tooling von VB6 und konkurrierenden Tools erstellt, außer dass der Code jetzt auf dem Server ausgeführt wird! Beeindruckend!

Dies war 2002 Technologie. Erstaunlich und schön in seiner Zeit als Antwort auf internetfähige GUI- Lösungen für die RAD- Entwicklung , brachte es ein Gefühl der Macht in eine chaotische Welt von Software-Entwicklern, die Geschäftsziele hatten, die sie erreichen mussten.

Leider betont dieses Programmiermodell die Metapher der Windows-GUI-Programmierung so sehr, dass es die Last seiner erforderlichen Implementierungsdetails mit sich bringt, all das belastende Gepäck, das erforderlich ist, um den Ereignislebenszyklen Rechnung zu tragen, und das Verstauen der hässlichen Details des einfachen HTML- und Skript, das diese Drag-and-Drop-Komponenten und Steuerelemente ausgeben würden. Letztendlich mussten Entwickler, die echte Anwendungen unterstützen, diese Komponenten gründlich untersuchen oder ihre eigenen Komponenten schreiben. Infolgedessen schlugen sie mit dieser Infrastruktur Schlachten, die Haufen über Haufen von Cruft, zerrissenen Haaren und Haaren hinterließen Tränen.

Sichern. Wasche deine Hände. Schauen wir uns das Geschäftsproblem noch einmal an. Was sind unsere Geschäftsziele?

Wir müssen Webanwendungen erstellen und verwalten . Unsere Einschränkungen sind, dass wir das World Wide Web haben, das auf HTTP, HTML, Javascript und CSS basiert, und auf dem Server Geschäftsregeln, Datenbanken und eine kleine Handvoll großartiger Programmiersprachen (z. B. C #). Brauchen wir wirklich diese Windows-GUI-Metapher, um unsere Entwicklungsmethodik voranzutreiben? Warum können wir uns nicht einfach auf die Anwendungsprobleme konzentrieren und die GUI-Metaphern beseitigen?

Hier kommt ASP.NET MVC ins Spiel. Es begann mit einer Rebellion von Entwicklern, die sich "Alt.Net" nannten und zu den richtigen und reinen Prinzipien der Softwareentwicklung zurückkehren wollten. Kein Aufwand mehr, konzentrieren Sie sich nur auf Geschäftsziele und bewährte Vorgehensweisen für Software.

Was dies in diesem Fall wirklich bedeutet, ist:

  1. Trennung von Bedenken . Beispielsweise muss eine Datenkomponente nicht wissen, wie ihre Daten gerendert werden sollen, und das View-Markup muss nicht mit Konfigurationsdetails für die Datenbankverbindung belastet sein. Auf diese Weise kann sich ein Entwickler beim Bearbeiten und Bearbeiten auf sein Anliegen konzentrieren Testcode.
  2. Offenlegung und volle Unterstützung für die Offenlegung des Kerns von HTML und verwandten Ressourcen . In Web Forms ist HTML versteckt, und Entwickler werden davon abgehalten, sich damit zu beschäftigen. In ASP.NET MVC werden Entwickler eher aufgefordert , diese Details zu verwalten. in der Tat ist es eine Notwendigkeit. Der Vorteil hierbei ist , dass der Entwickler wieder lernen , die saubere Semantik von HTML, CSS und Skript zu schätzen, und die Arbeit mit ihm und nicht gegen sie.
  3. Testbarkeit von Geschäftsobjekten . Controller und Modelle eignen sich viel besser für programmatische Komponententests, sodass Implementierungen validiert werden können, um die Geschäftsziele zu erreichen, und Änderungen überprüft werden können, damit sie nicht beschädigt werden. Mit Web Forms war es schwierig zu testen, da die Komponenten nicht einzeln getestet werden konnten und sich die gesamte Entwicklungsausgabe um Seitenformulare und deren Ereignislebenszyklen drehte, wobei Geschäftslogik und Präsentationslogik eng miteinander verflochten waren.

Beachten Sie, dass HTML bereits eine sehr hohe Auszeichnungssprache ist, ebenso wie Javascript eine hohe Programmiersprache. Die ganze Geschichte wäre anders gewesen, wenn wir uns mit Assemblersprache und C befasst hätten.

Neben # 2 besteht ein weiteres Ziel von ASP.NET MVC darin, Entwicklern die Möglichkeit zu geben, die Front-End-Details des Ansichtsbereichs ihrer Lösungen zu organisieren und von der umfassenden Grundlage zu profitieren, auf der der Rest der Branche aufgebaut hat die Front-End-Client-Plattform.

Sie werden feststellen, dass sich ASP.NET MVC-Entwickler mit umfangreichen Javascript-Bibliotheken und clientseitigen Template-Techniken wohl fühlen, ohne mit der serverseitigen Architektur zu kämpfen. Dies war ursprünglich bei ASP.NET Web Forms nicht der Fall, da Web Forms nicht möchte, dass Sie sich den HTML-Code oder das Skript überhaupt ansehen, es sei denn, Sie müssen wirklich aufpassen, dass dies nichts für schwache Nerven ist von Herzen.

stimpy77
quelle
Dies ist eine gute Antwort, aber # 1 und # 2 sind falsch (WF erfordert keine Komponente, um zu wissen, woher die Daten stammen. Es ist eine Option, und Sie haben Ihren ASPX-Dateien immer HTML hinzugefügt, um die von Ihnen verwendeten asp-Tags zu unterstützen . Rendering Sie haben nie die Kontrollen zu tief graben und kämpfen erforderlich , wenn Sie eine ASP - Funktion nicht für den Entwickler Interaktion zuzugreifen versuchen die großen Punkte sind Testbarkeit und Entwurfsmuster)..
Trisped
39

Ich bin eine vollständige und vollständige Konvertierung zu ASP.NET MVC und habe nicht zurückgeschaut, das heißt, ich muss noch einige sehr große WebForms-Apps warten. Hier ist meine Meinung dazu:

WebForms
Verwenden Sie diese Optionen, wenn Sie schwere Lasten mit Gittern zu tun haben. Die Rastersteuerelemente sind wirklich sehr nützlich, wenn Sie ein einfaches Dataset haben, das gut in ein Tabellenformat passt, und den Benutzern eine einfache Möglichkeit bieten möchten, Datensätze zu aktualisieren. Ja, ich weiß, dass MVC 4 eine wirklich pfiffige Ajax-Listensache hat, die Sie verwenden können und die hervorragend funktioniert, aber in unserem Geschäft müssen wir gestern oft etwas zum Laufen bringen, und gute, altmodische Grids funktionieren hervorragend, und die Benutzer sind froh, es zu sein in der Lage, mit Freude über ein Raster zu tappen. Für mich ist das wirklich das Beste an WebForms. aber als Ryanwies darauf hin, dass WebForms ein großes Durcheinander sein kann, da Sie beide Seiten des Fensters mit einer raffinierten Code-Behind-Datei abspielen. Es kann sowohl eine Rose als auch ein Dorn sein, um all Ihre Controller-artigen Dinge mit Ihren Ansichten zu vermischen.

MVC
Verwenden Sie diese Option, wenn Sie wirklich Ihre eigenen erstellen möchten und die Möglichkeit haben, eine Anwendung von Grund auf neu zu starten. Eine klar definierte MVC-Anwendung zu haben, ist ein wenig aufwändiger, aber die Vorteile in Bezug auf die Wartbarkeit überwiegen die anfänglichen Einrichtungskosten. Wenn Sie interessante Ajax-Interaktionen durchführen möchten, es vorziehen, Ihr Modell mit Code zu schreiben, z. B. mit sauberen URLs und Routen, und in der Lage zu sein, den gesamten Fluss Ihrer App zu steuern, ist dies definitiv der richtige Weg. Zuerst ist es etwas gewöhnungsbedürftig, aber ich denke, es ist die bessere Option für Greenfield-Apps.

Abschließend kommt es für mich auf Grids und! Grids an. :)

Nodey The Node Guy
quelle
+1 für das schöne Bild, das mit "Spielen beider Seiten des Zauns aus einer raffinierten Code-Behind-Datei" geliefert wurde.
Marcel
Sehr hilfreich dieses. Ich mache eine sehr schwere Grid-basierte App und habe Silverlight, xbap, ausgeschlossen und es war eine Show zwischen diesen beiden.
frostymarvelous
15

Meine Erfahrung:

  • Schrieb CakePHP-Projekte für ein Jahr.
  • Abschluss eines mittelgroßen Webforms-Projekts über sechs Monate.
  • Arbeitete drei Jahre an einem Windows Forms-Projekt.

Nach dieser Erfahrung habe ich versucht, eine andere App mit Webforms zu schreiben, und war frustriert, nachdem ich mich einen Tag lang mit dem Versuch von Webforms herumgeschlagen hatte, den Entwickler vor der Realität zu schützen, dass er eine Anwendung entwickelt, die HTML, Javascript und CSS verwendet.

Ich habe dann MVC ausprobiert und hatte eine direktere Kontrolle über die Ausgabe (und etwas Erfahrung mit dem MVC-Paradigma von CakePHP). Ich konnte diese einfache App genau so fertigstellen, wie ich es mir in ungefähr 1/2 Tag gewünscht hatte.

Die Verfügbarkeit leistungsfähiger UI-Frameworks wie jQuery macht es überflüssig, die direkte Kontrolle über die Ausgabe aufzugeben und häufig sperrige vorgefertigte UI-Komponenten zu verwenden.

Mootinator
quelle
2
@JimG - Uhh, alles, was es bedeutet, dass eine Person Datensätze ohne interessante Verknüpfungen in eine Datenbank eingibt und diese Person oder eine andere Person diese an einem anderen Punkt liest / druckt, kann im Grunde mit einem MVC-Framework gerüstet werden. Zugegeben, das sind nicht die meisten Apps, aber es ist viel mehr, als Sie mit Forms tun können. Ich denke, Ihre -1 beweist meinen Standpunkt.
Mootinator
1
Das ist ein viertel Tag.
Mootinator
1
Aber wenn die Anforderungen lauten: "Ich benötige eine App mit zwei Rollen, von denen eine Informationen aufzeichnet und die andere Informationen anzeigt. Es ist mir egal, wie sie aussehen." Dann ja, das ist durchaus machbar.
Mootinator
3
Es tut mir leid, aber die Entwicklung einer Webforms-App zur Eingabe und Anzeige von Daten ist so einfach, dass dies in wenigen Stunden erledigt werden kann. Das Erstellen der Struktur einer MVC-App (Controller, Ansichten und Aktionen) würde dieselbe Zeit in Anspruch nehmen, aber nicht zu einem fertigen Produkt führen.
Dementic
2
@Dementic Normalerweise erstellt man für eine einfache MVC-App Modelle, baut dann Controller und Ansichten auf und / oder generiert gerüstete Controller / Ansichten. Nichts wirklich zeitaufwändiges da.
Mootinator
8

Ich bevorzuge Webformulare, weil mein Hintergrund die Windows-Entwicklung ist.

Die Geschwindigkeit der Entwicklung ist ein Schlüsselproblem, und ich kann ein Problem leicht an jemanden in Indien weitergeben, um es über Nacht mit Formularen zu beheben. Wenn ich ein Geschwindigkeitsproblem auf einer Seite habe, ist ein wirklich gutes Buch über die Geschwindigkeit von asp.net praktisch (Rick Kiessig ist der Mann).

webforms ist für ex windows people mvc ist für web people

Aber in der modernen Welt, in der Rick ein großartiges Buch geschrieben hat, mit täglich schneller werdenden Servern und billigen Programmierern in Indien, haben Webformulare den Vorteil

Jason Palmer
quelle
7

Meine 2 Cent ist es, immer ASP.NET MVC für neue Projekte zu verwenden, wenn Sie die Option haben. Meiner Meinung nach ist Webforms kein guter Weg, um Web-Apps zu entwickeln.

Ich denke, es ist schlecht, grundlegende RESTs wegzuziehen, das gesamte Postback-Modell ist schlecht, die Art und Weise, wie HTML / CSS unter Berufung auf den GUI-Editor weitergegeben wird, ist schlecht, die Betonung von Dingen wie Assistenten und GUIs zum Einrichten von Dingen ist schlecht, die URLs sind schlecht.

scottschulthess
quelle
Können Sie uns näher erläutern, warum Sie das glauben?
Mücke
Ich denke, das Abstrahieren von grundlegendem REST ist zurück, das gesamte Postback-Modell ist zurück, die Art und Weise, wie HTML / CSS unter Berufung auf den GUI-Editor weitergegeben wird, ist schlecht, die Betonung von Dingen wie Assistenten und GUIs zum Einrichten von Dingen ist schlecht, die URLs sind schlecht, etc und so weiter
Scottschulthess
6

Ich habe alle Antworten gelesen und bin der Meinung, dass meine persönliche Erfahrung den obigen Antworten etwas hinzufügen würde.

Vor 3-4 Jahren habe ich 2-3 Website-Projekte mit Webforms entwickelt. Zu dieser Zeit war MVC nicht in der Nähe oder ich habe nichts davon gehört. Die Entwicklung war natürlich (ich stamme aus der Entwicklung von Windows-Formularen ohne vorherige Erfahrung in der Webentwicklung) schnell für mich, da ich HTML nicht in Details lernen muss und Web-Steuerelemente sehr geholfen haben (verdammt viel, es hat das Leben leichter gemacht). .

Jetzt, nach all der Zeit, habe ich bis vor kurzem kein Webprojekt mehr bearbeitet und lediglich eine Windows-Anwendung mit WPF erstellt.

Vor ein paar Tagen hatte ich eine Idee für eine Website und dachte darüber nach, sie zu entwickeln: diesmal in MVC (da es überall diskutiert wurde, musste ich auch lernen, also entschied ich mich für MVC). Das Projekt befindet sich noch in der Entwicklungsphase, da ich noch lerne und gemeinsam baue.

Also, die Hauptunterschiede, die ich zwischen den beiden finde, sind folgende:

  • Für jemanden, der aus der Windows-Entwicklung kommt, sind Webformulare immer günstig. Asp.net Lernkurve für einen Windows-Entwickler ist etwas steil

  • Für jemanden, der mit einer anderen Technologie aus der Webentwicklung kommt, wird MVC bevorzugt, da es sich über die neueste von allen lustig macht.

  • Die Entwicklung in MVC ist einfacher und sauberer, wenn Sie über gute Kenntnisse in HTML und CSS verfügen

  • Die Bereitstellung ist immer noch ein Problem. In Webformularen musste man nur kopieren und einfügen. Dazu müssen jedoch einige Dinge erledigt werden.

Kurz gesagt, beide werden für eine Weile hier bleiben.

Pankaj Upadhyay
quelle
6

Ich habe diese Überlegung unter den 15 Antworten auf diesen Thread noch nicht gesehen, aber ich denke, es lohnt sich, darüber nachzudenken.

Aus meiner Erfahrung ist Web Forms Win Forms und WPF ähnlicher als MVC. Vor diesem Hintergrund könnte man in Betracht ziehen, sich für Web Forms zu entscheiden, wenn das Team über die meiste Erfahrung mit dieser Art von Technologie verfügt oder wenn das Web Forms-Projekt eine Schnittstelle für denselben Datensatz bereitstellt wie vorhandene (oder gleichzeitig entwickelte) Win Forms oder WPF-Projekt. Auf diese Weise können Entwickler leichter zwischen Projekten wechseln, da die Anwendungslogik zwischen beiden sehr ähnlich sein kann.

Wie andere Antworten gezeigt haben, ähnelt die Entwicklung des MVC-Frameworks eher der Webentwicklung in Ruby, PHP, Python usw. als die von Microsoft. Daher kann die Wahl von MVC natürlich von der Erfahrung des Teams in diesen Bereichen beeinflusst werden, zusammen mit den Faktoren, die in anderen Antworten angegeben wurden.

Andy Hunt
quelle
+1 Sicherlich ein vernünftiges Argument für Webforms. Ich befürchte, dass Teams dieser Denkweise folgen, um nicht neue Dinge zu lernen. MVC ist mit vielen Mustern gefüllt, die einem Team möglicherweise unbekannt sind. Das Erlernen und Implementieren solcher Muster führt zu einer besseren Einhaltung der SOLID-Prinzipien, was zu einer insgesamt besseren Wartbarkeit führt. Diese bewährten Techniken sind auch der eigentliche Schlüssel zur Wiederverwendbarkeit.
P. Brian Mackey
3

Unser Grund, vor einigen Jahren nicht zu MVC zu gehen, war, dass es sich um eine unausgereifte Technologie von Microsoft handelte. In den letzten Jahren haben wir jetzt eine ausgereiftere Version (4) und MS scheint herausgefunden zu haben, wohin sie damit gehen. Wir zögern jedoch weiterhin, wichtige Branchenanwendungen mit MVC zu entwickeln, da für die Funktionen, die wir in Version 4 verwenden möchten, ein Windows 2012-Server erforderlich ist (für Web-Sockets über IIS8). Ich gehe davon aus, dass wir MVC in einem weiteren Jahr mehr akzeptieren werden, da hoffentlich mehr Kontrollen von Drittanbietern verfügbar sein werden, sich die Technologie stabilisiert hat und wir über die Infrastruktur verfügen werden, um dies zu unterstützen.

Steve
quelle
1
Würde es Ihnen etwas ausmachen, einige dieser Funktionen aufzulisten, die Ihrer Meinung nach Windows Server 2012 erfordern?
MikeTeeVee
2

Diese Entscheidung hängt von Ihren Vorlieben, Ihren Anforderungen oder sogar Ihren Kenntnissen und Erfahrungen ab.

Die Zeit für das Lernen von MVC oder die Zeit, um eine Lieferung zu erhalten. All dies ist wichtig, um den einen oder anderen Ansatz zu wählen.

Ist nicht das eine besser als das andere, haben einfach beide Ansätze oder Rahmenbedingungen Vor- und Nachteile.

Ich persönlich bevorzuge MVC 3, ich empfehle Ihnen, eine eigene Erfahrung zu machen, aber ich muss sagen, dass das Programm in MVC eine saubere, unterhaltsame, flexible, erweiterbare, sichere und strukturierte Art ist.

Grüße,

pacoespinoza
quelle
2

Der einzige Grund, warum ich mich für die WebForms anstelle von MVC entschieden habe, ist, dass Sie für WebForms wesentlich mehr UI-Steuerelemente von Drittanbietern als für MVC haben. Ich habe mich für MVC entschieden, weil ich zu viel mit WebForms gearbeitet habe und mit etwas Neuem arbeiten möchte, aber immer noch von MS Shop :)

Grundsätzlich hindert nichts Sie daran, den Viewstate in WebForms auszuschalten und ViewModels und if / for-Schleifen anstelle der Modellbindung und serverseitigen Steuerelemente zu verwenden.

Ist das WebForms oder MVC Code:

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

Die einzige Einschränkung, die ich in WebForms gefunden habe, ist, dass Sie bei Verwendung von Abhängigkeitsinjektion / Inversion der Steuerung keine Konstruktorinjektion verwenden können, da WebForms-Seiten über einen parameterlosen Konstruktor verfügen müssen, sodass Sie die Eigenschaftsinjektion verwenden müssen. Ist das wirklich so eine große Sache?

šljaker
quelle
1

ASP.NET MVC ist wirklich eine Antwort auf Ruby und die neue, trendige und (IMO) bessere Möglichkeit, den Browser (Client) so weit wie möglich vom Server zu entkoppeln.

Mit ASP.NET Webforms können Sie den Client weitgehend vom Server aus steuern und haben direkten Zugriff auf so ziemlich alles. Im Wesentlichen sind Ihre Ansicht und Ihr Controller ein und dasselbe, was Ihnen viel Kraft und meistens viel Chaos verleiht.

ASP.NET MVC trennt die Ansicht und den Controller, indem die enge Kopplung zwischen einer ASPX-Datei und der ASPX.CS-Datei, die in Webformularen enthalten ist, aufgehoben wird.

Im Wesentlichen besteht der Unterschied darin, dass Sie wesentlich mehr (in der Regel alles) für die Anzeige von Daten in der Ansichtsdatei benötigen und die Geschäftslogik und den Rest auf dem Controller belassen, um beide Funktionen sauberer zu halten, aber auch weniger Zugriff auf die einzelnen Funktionen zu haben andere als Webformulare ermöglicht.

Ryan Hayes
quelle
WANN sollten Webformulare gegenüber MVC bevorzugt werden? Dies beantwortet nicht die Frage nach dem Originalposter.
Steven Striga
@WeekendWarrior - Wenn Sie mehr serverseitigen Zugriff auf den Client wünschen, wählen Sie Webformulare. Wenn Sie eine stärkere Entkopplung von Client / Server in Ihrem Code wünschen, wählen Sie MVC. Am Ende des Tages machen beide genau dasselbe. Umleitungsfilter verhalten sich genauso wie die MVC-URLs, und Sie können den Webforms-Code in eine separate mittlere Ebene verschieben, um ihn stärker zu entkoppeln. weblogs.asp.net/scottgu/archive/2010/01/24/…
Ryan Hayes
In Bezug auf Ihren dritten Punkt landet diese Geschäftslogik in der .aspx.cs-Datei - ich denke, das ist die Schuld der Entwickler. Es soll nicht da sein. In Webforms ist .aspx die "Ansicht", .aspx.cs die "Steuerung", die den Code verarbeiten soll, der sich nur auf die Benutzeroberfläche bezieht, indem eine Geschäftsschicht oder eine grobkörnige Geschäftsfassadenschicht abgefragt wird. Die Tatsache, dass die Leute Geschäftslogik in die .aspx.cs einfügen, ist nur schlechte Programmierung. Sie könnten auch die Geschäftslogik in MVC richtig in Szene setzen! MVC erzwingt keine Trennung dieser Dinge.
James
Im Grunde hat er mehr Recht als andere Antworten, die hier gepostet wurden. ASP.net ist die Grundidee einer modularen Webtechnologiefamilie von Microsoft. Das ASP.net-MVC-Modul mag ein zeitweiliger Hype sein, aber es ist sicher nicht das letzte. Alles beginnt mit ASP.net. Wenn Sie also nicht glauben, dass MVC nicht Ihr Ding ist, ist es vielleicht Ihr größeres Anliegen sonst OWIN oder ..., etwas Fortgeschritteneres oder ein eigenes Framework für Ihre Aufgaben. Sie brauchen vielleicht nicht einmal ASP.MVC und überspringen es und gehen zu Owin oder Katana, aber bis Sie dort asp.net
user3800527 24.10.16
1

Meiner Meinung nach sind sie miteinander verwandt und haben ungefähr die gleichen Fähigkeiten, die es zu bevorzugen gilt.

Ein großartiger WebForms-Entwickler kann ein Produkt produzieren, das genauso leistungsfähig ist wie ein großartiger MVC-Entwickler. Aber der großartige WebForms-Entwickler, der versucht, sich dazu zu zwingen, MVC einzuführen, wird nicht weiterkommen. Gleiches gilt für einen großartigen MVC-Entwickler, der WebForms eine Chance gibt.

Sie sind keine völlig getrennten Einheiten, und solange Microsoft beide weiterhin unterstützt, werden Sie meiner Meinung nach weiterhin eine gemischte Gruppe außergewöhnlicher Entwickler zu sehen bekommen.

user29981
quelle
0

Hier geht es um die persönliche Wahl, vorausgesetzt, wir alle beherrschen die von uns verwendete Technologie. Ich verwende den WebForms-Designansatz seit vielen Jahren, und ich muss sagen, dass der einzige Nachteil darin besteht, dass sich viele Menschen aufgrund seines vereinfachten Ansatzes nicht die Zeit nehmen, seine enormen Fähigkeiten zu entdecken.

Ich habe vor kurzem MVC verwendet, um ein Projekt abzuschließen, und obwohl mir der Designansatz für die Anwendungsentwicklung (der Ihnen mehr Kontrolle, saubere URLs, SOC usw. bietet) sehr gut gefällt, gibt es wirklich nicht viel, was WebForms nicht kann. In der Tat hat die Entstehung von jQuery und die Zusammenarbeit mit WebForms (sowie MVC) diese Argumente weniger problematisch gemacht. Und wenn Leute über die Trennung von Anliegen als Vorteil sprechen, den MVC gegenüber MVP hat, frage ich sie, wie viel sie über objektorientierte Programmierung wissen und wie viel sie das Prinzip der Abstraktion und des Polymorphismus anwenden.

Ich bin derzeit mit beiden Technologien vertraut und wähle sie situationsabhängig aus. Ehrlich gesagt liegt es an Ihnen, aber die Wahrheit ist, dass sich nicht jeder die Zeit nimmt, um zu erfahren, wozu eine bestimmte Technologie in der Lage ist.

David Grant
quelle
Das Gleiche gilt für die umfangreichen Funktionen von Webformularen. Die meisten Leute sehen die Trainingsräder von Webforms und vergleichen diese mit MVC.
TheLegendaryCopyCoder
Heutzutage (auch 2013) ist es wenig sinnvoll, eine Abstraktion über HTML und Javascript zu lernen. Es wird dir nicht gut tun für deine zukünftigen Gelegenheiten. HTML und Javascript sind in Ordnung so wie es ist. Es zu kämpfen ist eine verlorene Schlacht.
user441521
0

Wenn ich mit einem Programmierproblem konfrontiert bin, schaue ich oft im Internet nach Antworten. Webforms bietet Unmengen an Informationen und Komponenten, mit denen Sie fast alles erledigen können. In MVC sind aufgrund der geringeren Anzahl an Online-Quellen und der Abstraktionsebenen, die erforderlich sind, um etwas zum Laufen zu bringen, Grenzen für die Dinge gesetzt, die ich einst tun konnte. MVC total bringt meine Produktivität als Entwickler zum Erliegen, mit Webforms nicht. Im Moment halte ich mich also an Webformulare, bis MVC ausgereift ist, um sie zu ersetzen.

Sonny
quelle
0

Nun, in WebForms stehen mehr Lernressourcen zur Verfügung (einfach aufgrund der Tatsache, dass es älter ist), und daher werden neue Programmierer, die nicht "im Wissen" sind, eher Informationen zu dieser älteren Technologie finden als zu neueren Dingen wie MVC .

Ältere / erfahrene Programmierer sind älter und beherrschen die ältere Technologie aufgrund der Tatsache, dass sie länger darin programmiert haben als in der neueren.

Wenn Sie nicht das Geld und die Mühe aufwenden können, um Ihre Mitarbeiter mit MVC so vertraut zu machen wie mit WebForms-Anwendungen, werden Sie zweifellos versuchen, ein Upgrade auf die neue Plattform so lange wie möglich zu unterbinden.

Daher ergeben sich mehrere logistische Probleme: Wiegen die Vorteile von MVC die Kosten in Bezug auf geringere Qualität und Bereitstellungszeit auf? Wenn ich eine Website vollständig in WebForms geschrieben habe, lohnt sich der Aufwand und das Geld, um MVC darin zu integrieren?

Wie von einem früheren Kommentator angegeben, verhindert MVC auch, dass Sie dieselbe Schnittstelle zum Controller erreichen, die Sie mit WebForms erreichen können. Ich bin zwar nur für die Seite "Benutzer davon abhalten, Dinge zu stopfen / zu lernen", aber es kann für Teams immer noch unangemessen schwierig sein, ein Programm bereitzustellen / zu implementieren, das sich bei allem, was sie schreiben, fanatisch an dieses Paradigma hält.

user32288
quelle
-1

Ich denke, die Kluft zwischen diesen beiden Technologien ist nicht mehr so ​​groß wie früher.

  • Webformulare können das von MVC verwendete (oder ein sehr ähnliches) Routingmodul verwenden.
  • Der Skriptmanager kann Skripte kombinieren, von einem CDN laden und sogar das Laden von Skripten verzögern.

Um Ihre Frage direkt zu beantworten, kommt es meiner Meinung nach auf die Vorlieben und / oder das Projekt an. Beide verfolgen einen deutlich unterschiedlichen Entwicklungsansatz. Persönlich habe ich an der Umstellung auf MVC gearbeitet, aber es macht mir immer noch Spaß, mit Webforms zu arbeiten. Ich denke, die Antwort auf die Frage, ob Sie MVC oder Webforms verwenden sollten, liegt darin, dass Sie beide Technologien kennenlernen.

Der Muffin-Mann
quelle
1
Webforms und MVC empfehlen standardmäßig eine radikal andere Webentwicklungshaltung. Dies ist wichtig , da nur wenige Entwickler von der "Standardeinstellung" abweichen. Beide können verwendet werden, um dasselbe zu erreichen.
Raynos