it-swarm.dev

Wann sollten ASP.NET WebForms gegenüber MVC bevorzugt werden?

Ich weiß, dass Microsoft gesagt hat

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

Und einige Entwickler sagen, dass WebForms schneller zu entwickeln ist als MVC. Ich glaube jedoch, dass die Geschwindigkeit der Codierung mit der Technologie auf dem Komfortniveau liegt, daher möchte ich keine Antworten in diesem Sinne.

Warum wird WebForms nicht als veraltet angesehen, da ASP.NET MVC einem Entwickler mehr Kontrolle über seine Anwendung gibt? Wann sollte ich alternativ WebForms für Neuentwicklungen gegenüber MVC bevorzugen?

192
P.Brian.Mackey

Webforms vs. MVC scheint derzeit ein heißes Thema zu sein. Jeder, den ich kenne, wirbt dafür, dass MVC das nächste große Ding ist. Aufgrund meiner leichten Versuche scheint es in Ordnung zu sein, aber nein, ich glaube nicht, dass dies das Ende von Webformularen sein wird.

Meine Überlegungen und die Gründe, warum Webformulare gegenüber MVC ausgewählt werden, haben mehr 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 größte Teil Ihres Teams Webformulare kennt und Sie nicht die Zeit haben, diese auf MVC auf den neuesten Stand zu bringen, ist der Code, der erstellt wird, möglicherweise nicht von Qualität. Das Erlernen der Grundlagen von MVC, das Einspringen und Ausführen der komplexen Seite, die Sie ausführen müssen, sind sehr unterschiedliche Dinge. Die Lernkurve ist hoch, daher müssen Sie dies in Ihr Budget einbeziehen.

Wenn Sie eine große Website haben, die ausschließlich in Webformularen geschrieben ist, sind Sie möglicherweise eher geneigt, neue Seiten in Webformularen 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 macht es schwieriger, Ihren Code zu pflegen, wenn es eine Aufteilung von beiden gibt, insbesondere wenn nicht jeder im Team mit MVC vertraut ist.

Mein Unternehmen 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 Anzeigen und Bearbeiten auf derselben Seite haben. Wir brauchten mehr als ein Formular auf der Seite. Kein Problem, außer dann würden wir unsere Masterseite nicht verwenden. Wir mussten dies überarbeiten, damit sowohl die Webformseiten als auch die MVC-Seiten dieselbe Masterseite für ein gemeinsames 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 richtigen MVC-Trennung folgte.

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 Webformulare gegenüber MVC wählen, wenn Sie nicht die Zeit/das Geld haben, um in die Aktualisierung Ihrer Website für die Verwendung von MVC zu investieren. Wenn Sie dies halbherzig angehen, wird es nicht besser sein als die Webformulare, die Sie jetzt haben. Schlimmer noch, Sie könnten diese Technologie sogar für einen Ausfall in Ihrem Unternehmen einrichten, wenn sie durcheinander ist, da das obere Management sie möglicherweise als etwas minderwertiges ansieht, als es weiß.

105
Tyanna

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

  • Die Seitenlebensdauer ist einfacher und effizienter
  • Außer HTML-Steuerelementen gibt es keine Steuerelemente. Sie müssen Ihre Ausgabe nicht debuggen, um zu sehen, was ASP .Net generiert.
  • ViewModels bieten Ihnen immense Leistung und machen das manuelle Binden von Steuerelementen überflüssig. Außerdem werden viele Fehler im Zusammenhang mit dem Binden vermieden.
  • 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 Web. 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, sodass er sich nicht immer so verhält, wie Sie es möchten.
  • Webanwendungen müssen heutzutage mit Ajax arbeiten. Es ist nicht mehr akzeptabel, dass ganze Seiten geladen werden. MVC macht Ajax mit JQuery so viel besser, einfacher und effizienter.
  • Da eine Seite mehrere Formulare enthalten kann und die Architektur durch Aufrufe von URLs gesteuert wird, können Sie mit JQuery funky Dinge wie Ajax ausführen, um ein anderes Formular wie ein Bearbeitungsformular in Ihre aktuelle Seite zu laden. Sobald Sie erkennen, was Sie damit tun können, können Sie leicht erstaunliche Dinge tun.
  • ASP .Net WebForms ist nicht nur eine Abstraktion über HTML, sondern auch eine äußerst komplexe. Manchmal bekam man einen seltsamen Fehler und kämpfte viel länger damit als nötig. In vielen Fällen konnten Sie tatsächlich sehen, was falsch lief, aber Sie können nichts dagegen tun. Am Ende machen Sie seltsame Problemumgehungen.
  • WebForms ist keine gute Technologie für Designer. Designer arbeiten oft gerne direkt mit HTML. In MVC ist es eine Ansicht, in WebForms ist es ein halber Arbeitstag.
  • Da sich die Webplattform schnell weiterentwickelt, werden WebForms nicht mithalten können. Es sind keine neuen Tags oder Funktionen von HTML5 bekannt. Es wird jedoch immer noch dasselbe 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 Weiterentwicklung 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.

190
Tjaart

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

"Unterschiedliche 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 bedeutet dies, dass es sich nicht um ein technisches Problem handelt. Es ist eher ein "weiches Problem", wenn Sie so wollen. Eine persönliche Präferenz. Dies steht im Einklang mit dem, was einige von Ihnen gesagt haben.

Danke für alle Antworten.

80
P.Brian.Mackey

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 von Ihnen erwartet, dass Sie wissen, wie HTML und clientseitige Ressourcen (Javascript, CSS) funktionieren, und dass Sie die MVC-Programmier-Denkweise verbessern, die eine steile Lernkurve aufweist, aber nach dem Erfassen ein plötzliches Ende erreicht.
  • Verwenden Sie ASP.NET Web Forms, wenn Sie ein GUI - centric, RAD (Rapid Application Development) verwenden , Drag-and-Drop-Ansatz für das sehr schnelle Prototyping von Objekten, dh das Verhalten von Drucktasten/Datengittern, das innerhalb von 15 Minuten verkabelt wurde, und die Lösung soll nicht von Entwicklern unterstützt werden. Oder Verwenden Sie ASP.NET Web Forms, wenn Sie einen Hintergrund in der Entwicklung von GUI oder Windows Forms haben und übertragen möchten Ihr Wissen ins Web.

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. Zu dieser Zeit Webentwicklung mit Diese Microsoft-Tools waren ein echtes Durcheinander. Zusammen mit der Gesamtheit von .NET Framework, das die Ausgabe von Microsoft war, ging ASP.NET Web Forms im Wesentlichen auf das Reißbrett zurück, wie produktive Geschäftsprogrammierung auf dem Windows-Stack durchgeführt werden kann Es ist Tag, unglaublich 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 die Leistungsfähigkeit von Internetdiensten bietet. Die Idee war, dass genau wie bei einem VB6/WinForms "Formular" (einem Fenster) auch eine Webseite ein Formular ist (genau wie ein Fenster, siehe) , und darauf In diesem Formular können Sie Beschriftungen, Textfelder, Datenraster, Schaltflächen und andere Dinge, an die die Entwickler der VB/WinForms-Benutzeroberfläche gewöhnt waren, per Drag & Drop verschieben.

Um eine Schaltfläche dazu zu bringen, etwas zu tun, doppelklicken Sie nach dem Ziehen und Ablegen im Designer einfach darauf und boomen Sie im Code-Editor, um dem Formular mitzuteilen, was zu tun ist, wenn dieses "Klick" -Ereignis auftritt. Genau so haben Windows-GUI-Entwickler Software mit GUI Werkzeugen von VB6 und konkurrierenden Werkzeugen erstellt, außer jetzt die Code wird auf dem Server ausgeführt! Beeindruckend!

Dies war 2002 Technologie. Erstaunlich und schön in seiner Zeit als Antwort auf internetfähige GUI Lösungen für RAD Entwicklung, es brachte ein Gefühl der Macht in eine chaotische Welt von Softwareentwicklern, 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 notwendigen Implementierungsdetails, des gesamten belastenden Gepäcks, das zur Anpassung an die Ereignislebenszyklen erforderlich ist, und das Verstecken der hässlichen Details des einfachen HTML- und HTML-Codes mit sich bringt Skript, das diese Drag & Drop-Komponenten und Steuerelemente ausgeben würden. Und am Ende des Tages mussten Entwickler, die echte Anwendungen unterstützen, unweigerlich tief in diese Komponenten eindringen oder ihre eigenen schreiben, und folglich kämpften sie mit dieser Infrastruktur, Schlachten, die Haufen auf Haufen von Kruft, gezogenen Haaren und Tränen.

Sichern. Wasch 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 bestehen darin, 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 #). Benötigen wir diese Windows-GUI-Metapher wirklich, 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 Schnickschnack mehr, konzentrieren Sie sich nur auf Geschäftsziele und Best Practices für Software.

Was dies in diesem Fall wirklich bedeutet, ist:

  1. Trennung von Bedenken . Beispielsweise muss eine Datenkomponente weder wissen, wie ihre Daten gerendert werden sollen, noch sollte das Ansichts-Markup mit Details zur Konfiguration der Datenbankverbindung belastet sein. Auf diese Weise kann sich ein Entwickler beim Bearbeiten und auf sein Anliegen konzentrieren Testcode.
  2. Offenlegung und volle Unterstützung für die Exposition gegenüber dem Kern von HTML und verwandten Ressourcen . In Web Forms ist HTML versteckt, Entwickler werden davon abgehalten, sich damit zu beschäftigen. In ASP.NET MVC werden Entwickler eher ermutigt, um diese Details zu verwalten. in der Tat ist es eine Notwendigkeit. Der Vorteil hierbei ist, dass der Entwickler erneut lernen kann, die saubere Semantik von HTML, CSS und Skript zu schätzen und mit und nicht dagegen zu arbeiten.
  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, dass sie nicht beschädigt werden. Mit Web Forms war es schwierig zu testen, da Komponenten nicht für den individuellen Test konzipiert wurden und sich die gesamte Entwicklungsausgabe um Seitenformulare und deren Ereignislebenszyklen drehte, wobei der Dreck aus Geschäftslogik und Präsentationslogik eng miteinander verflochten war .

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

Ein weiteres Ziel von ASP.NET MVC ist es, Entwicklern die Möglichkeit zu geben, die Front-End-Details des Ansichtsteils ihrer Lösungen zu organisieren und die umfassende Grundlage zu nutzen, 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 wie zu Hause 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 HTML oder Skript überhaupt ansehen, außer wenn Sie wirklich müssen In diesem Fall Vorsicht, es ist nichts für schwache Nerven.

44
stimpy77

Ich bin eine vollständige und vollständige Konvertierung in ASP.NET MVC und habe nicht zurückgeschaut, dass ich immer noch mehrere sehr große WebForms-Apps warten muss. Hier ist meine Meinung dazu:

WebForms
Verwenden Sie diese, wenn Sie ernsthaftes Heben im Zusammenhang mit Gittern haben. Die Rastersteuerelemente sind wirklich sehr hilfreich, wenn Sie ein einfaches Dataset haben, das gut in ein Tabellenformat passt, und Benutzern eine einfache Möglichkeit zum Aktualisieren von Datensätzen bieten möchten. 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 glücklich darüber in der Lage, mit Freude über ein Gitter zu tippen. Für mich ist das wirklich das Beste an WebForms. Aber, wie Ryan betonte, können WebForms ein großes Durcheinander sein, da Sie beide Seiten des Zauns aus einer raffinierten Code-Behind-Datei spielen. Es kann gleichzeitig eine Rose und ein Dorn sein, um all Ihre Controller-artigen Dinge mit Ihren Ansichten zu vermischen.

[~ # ~] mvc [~ # ~]
Verwenden Sie diese Option, wenn Sie wirklich Ihre eigenen Rollen 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 bisschen mehr Arbeit, aber die Vorteile in Bezug auf die Wartbarkeit überwiegen die anfänglichen Einrichtungskosten. Wenn Sie interessante Ajax-Interaktionen durchführen möchten, Ihr Modell lieber mit Code wie sauberen URLs und Routen schreiben und den gesamten Fluss Ihrer App steuern möchten, ist dies definitiv der richtige Weg. Anfangs ist es etwas gewöhnungsbedürftig, aber ich denke, es ist die bessere Option für Greenfield-Apps.

Zusammenfassend kommt es für mich auf Gitter und! Gitter an. :) :)

39

Meine Erfahrung:

  • Schrieb ein Jahr lang CakePHP-Projekte.
  • 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 Webformularen zu schreiben, und war frustriert, nachdem ich ungefähr einen Tag lang damit zu kämpfen hatte, wie Webformulare versuchen, den Entwickler vor der Realität zu schützen, dass sie eine Anwendung entwickeln, die HTML, Javascript und CSS verwendet.

Ich habe dann MVC ausprobiert und hatte eine direktere Kontrolle über die Ausgabe (und einige Erfahrungen mit dem MVC-Paradigma von CakePHP). Ich konnte diese einfache App in ungefähr einem halben Tag genau so fertigstellen, wie ich es wollte.

Die Verfügbarkeit leistungsfähiger UI-Frameworks wie jQuery eliminiert den Reiz, die direkte Kontrolle über die Ausgabe zugunsten der Verwendung häufig umfangreicher vorgefertigter UI-Komponenten aufzugeben.

15
mootinator

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

Die Geschwindigkeit der Entwicklung ist ein zentrales Problem, 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 Servern, deren Geschwindigkeit täglich zunimmt, und billigen Programmierern in Indien, haben Webformulare den Vorteil

8
jason palmer

Meine 2 Cent sind, 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, das Abstrahieren von Basic REST ist schlecht, das gesamte Postback-Modell ist schlecht, die Art und Weise, wie HTML/CSS mit dem GUI-Editor übergeben wird, ist schlecht, die Betonung auf Dingen wie Assistenten und GUIs Sachen einzurichten ist schlecht, die URLs sind schlecht.

7
scottschulthess

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 da oder ich habe nichts davon gehört. Die Entwicklung war natürlich (ich kam aus der Win-Forms-Entwicklung ohne vorherige Erfahrung in der Webentwicklung) schnell für mich, da ich HTML nicht in Details lernen muss und Web-Controls sehr geholfen haben (verdammt viel, es hat das Leben einfacher gemacht). .

Nach all dieser 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 überall darüber gesprochen wird, außerdem musste ich auch lernen, also wähle ich MVC). Das Projekt befindet sich noch in der Entwicklungsphase, da ich noch zusammen lerne und baue.

Also, die Hauptunterschiede, die ich s/w finde, sind die folgenden: -

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

  • Für jemanden, der aus der Webentwicklung in einer anderen Technologie stammt, wird MVC bevorzugt, da es die neueste von allen verspottet.

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

  • Die Bereitstellung ist immer noch ein Problem. In Webformularen musste man nur kopieren und einfügen. Dies erfordert jedoch einige Dinge zu tun.

Kurz gesagt, beide werden eine Weile hier bleiben.

6
Pankaj Upadhyay

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, Web Forms zu wählen, wenn das Team die meiste Erfahrung mit dieser Art von Technologie hat oder wenn das Web Forms-Projekt eine Schnittstelle zu demselben Datensatz wie ein vorhandenes (oder gleichzeitig entwickeltes) Win Forms oder bereitstellt 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 beeinflusst werden Die Erfahrung der Teams in diesen Bereichen sowie die in anderen Antworten angegebenen Faktoren.

6
Andy Hunt

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 immer noch, wichtige LOB-Apps 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, die Technologie sich eingestellt hat und wir über die Infrastruktur verfügen, um dies zu unterstützen.

3
Steve

Diese Entscheidung hängt von Ihren Vorlieben, Ihren Anforderungen oder sogar von Ihrem Wissen und Ihrer Erfahrung ab.

Die Zeit für das Training, um MVC zu lernen, oder die Zeit, um eine Lieferung zu erhalten. All diese Dinge sind wichtig, um den einen oder anderen Ansatz zu wählen.

Ist nicht, dass einer besser ist als der andere, haben einfach beide Ansätze oder Rahmenbedingungen Vor- und Nachteile.

Persönlich bevorzuge ich MVC 3, ich empfehle Ihnen, Ihre eigenen Erfahrungen zu sammeln, aber ich muss sagen, dass das Programm in MVC eine saubere, unterhaltsame, flexible, erweiterbare, sichere und strukturierte Methode ist.

Grüße,

2
pacoespinoza

Der einzige Grund, warum ich WebForms anstelle von MVC wählen würde, ist, dass Sie für WebForms viel 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 Frischem/Neuem arbeiten möchte, aber immer noch aus dem MS-Shop :)

Grundsätzlich hindert Sie nichts daran, den Ansichtsstatus in WebForms zu deaktivieren und ViewModels und if/for-Schleifen anstelle von Modellbindung und serverseitigen Steuerelementen 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 Dependency Injection/Inversion of Control keine Konstruktorinjektion verwenden können, da WebForms-Seiten einen parameterlosen Konstruktor haben müssen, sodass Sie die Eigenschaftsinjektion verwenden müssen. Ist das wirklich so eine große Sache?

2
šljaker

Meiner Meinung nach sind sie verwandt genug 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 zur Einführung von MVC zu zwingen, wird zu kurz kommen. Gleiches gilt für einen großartigen MVC-Entwickler, der WebForms eine Chance gibt.

Sie sind keine vollständig getrennten Einheiten, und solange Microsoft beide weiterhin unterstützt, werden Sie meiner Meinung nach weiterhin eine gemischte Gruppe außergewöhnlicher Entwickler für jede Einheit sehen.

1
user29981

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.

ASP.NET Webforms gibt Ihnen viel Kontrolle über den Client von der Serverseite aus, mit direktem Zugriff auf so ziemlich alles. Im Wesentlichen sind Ihre Ansicht und Ihr Controller ein und dasselbe, was Ihnen viel Leistung und meistens viel Chaos gibt.

ASP.NET MVC trennt die Ansicht und den Controller, indem die enge Kopplung einer ASPX-Datei und der ASPX-CS-Datei, die sie in Webformularen begleitet, getrennt wird.

Im Wesentlichen besteht der Unterschied darin, dass Sie viel mehr (normalerweise die gesamte) Verarbeitung durchführen, um Daten in der Ansichtsdatei anzuzeigen und die Geschäftslogik und den Rest zu belassen in der Steuerung, um beide gemäß Konvention sauberer zu halten, aber auch mit weniger Zugriff aufeinander, als es Webformulare erlauben.

1
Ryan Hayes

Nun, WebForms verfügen über mehr Lernressourcen (einfach aufgrund der Tatsache, dass es älter ist), und daher werden neue Programmierer, die nicht "Bescheid wissen", eher Informationen zu dieser älteren Technologie finden als neuere wie MVC .

Ältere/erfahrene Programmierer sind älter und beherrschen die ältere Technologie besser, da 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 so gut mit MVC vertraut zu machen wie mit WebForms-Anwendungen, werden Sie zweifellos versuchen, das Upgrade auf die neue Plattform so lange wie möglich zu unterbinden.

Es gibt also mehrere logistische Probleme: Wiegen die Vorteile von MVC die Kosten in Bezug auf geringere Qualität und Bereitstellungszeit auf? Wenn ich eine Site vollständig in WebForms geschrieben habe, wäre es die Mühe und das Geld wert, MVC in diese zu integrieren?

Wie bereits von einem früheren Kommentator erwähnt, verhindert MVC auch, dass Sie dieselbe Schnittstelle mit dem Controller erreichen, wie dies mit WebForms möglich wäre. Ich bin zwar alles für die Seite "Den Benutzer davon abhalten, Dinge zu stopfen/zu lernen", aber es kann für Teams immer noch unangemessen mühsam sein, ein Programm bereitzustellen/zu implementieren, das sich fanatisch an dieses Paradigma für alles hält, was sie schreiben.

0
user32288

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

Ich habe kürzlich MVC verwendet, um ein Projekt abzuschließen, und obwohl mir der Entwurfsansatz für die Anwendungsentwicklung (der Ihnen mehr Kontrolle, saubere URLs, SOC usw. bietet) sehr gefällt, gibt es wirklich nicht viel, was WebForms nicht kann. Tatsächlich haben das Aufkommen von jQuery und die Zusammenarbeit mit WebForms (sowie MVC) diese Argumente weniger problematisch gemacht. Und wenn Leute über die Trennung von Bedenken 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 je nach Situation aus. Ehrlich gesagt liegt es an Ihnen, aber die Wahrheit bleibt, dass sich nicht jeder Zeit nimmt, um gründlich zu lernen, wozu eine bestimmte Technologie in der Lage ist.

0
David Grant

Wenn ich mit einem Programmierproblem konfrontiert bin, suche ich oft im Internet nach Antworten. Webforms enthält unzählige Informationen/Komponenten, mit denen Sie nahezu alles tun können. In MVC haben aufgrund der geringeren Online-Quellen und der Abstraktionsebenen, die erforderlich sind, damit etwas funktioniert, die Dinge, die ich einmal tun konnte, Grenzen gesetzt. MVC total beeinträchtigt meine Produktivität als Entwickler, während dies bei Webforms nicht der Fall ist. Daher halte ich mich vorerst an Webformulare, bis MVC ausgereift genug ist, um sie zu ersetzen.

0
Sonny