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

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?

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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,

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?

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.

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.

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.

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.

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.

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.