Wann ASP.NET WebForms gegenüber MVC bevorzugt werden

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 Überlegungen, 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 die meisten von Ihnen Das Team kennt Webformulare, und Sie haben nicht die Zeit, sie auf MVC auf den neuesten Stand zu bringen. Der Code, der erstellt wird, ist möglicherweise nicht von Qualität. Das Erlernen der Grundlagen von MVC, das Einspringen und Erstellen 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 vollständig in Webforms geschrieben ist, sind Sie möglicherweise eher geneigt, neue Seiten in Webforms zu erstellen, damit Sie nicht “ Es gibt keine zwei sehr unterschiedlichen Seitentypen auf Ihrer Website.

Ich sage hier nicht, dass es sich um einen Alles-oder-Nichts-Ansatz handelt, aber es macht es schwieriger, Ihren Code zu pflegen, wenn es eine Aufteilung von beiden gibt Besonders 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 vorhanden sind Die Funktionen zum Anzeigen und Bearbeiten auf derselben Seite. Wir benötigten letztendlich mehr als ein Formular auf der Seite. Kein Problem, außer dann würden wir unsere Masterseite nicht verwenden. Wir mussten das ü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 zu viele Dateien für 3 Seiten vorhanden waren, 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 zu investieren, um MVC zu verwenden. Wenn Sie diesbezüglich einen halbherzigen Ansatz verfolgen, Es wird 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 das, was sie wissen.

Kommentare

• Dies ist eine gute Antwort. Ich habe Ihnen +1 gegeben, weil Ihre 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 eine Technologie aus Angst vor der Lernkurve für MVC nicht als veraltet markieren würde. Dies mag der Fall sein, aber ich ‚ bin noch nicht überzeugt.
• @ P.Brian.Mackey – Ich habe nicht ‚ gesagt, dass die Formularentwicklung schneller ist als MVC. Sie haben darum gebeten, dieses Argument wegzulassen. Das Streiten von Zeit und Geld für die Schulung Ihrer Mitarbeiter ist ein anderes Argument. MS wird ‚ Webformulare nicht als veraltet markieren, und zwar aus einem wichtigen Grund: Unternehmenskunden haben Jahre damit verbracht, Webclients in Webforms zu entwickeln, und ‚ Sie müssen nicht unbedingt Zeit und Geld investieren, um ein Update durchzuführen.
• @Raynos – Wenn alle Mitglieder des Teams MVC beherrschen und Ihr Unternehmen ein neues Projekt startet, ist der einzige Grund, warum ich jemanden sehen konnte, der sich für Webformulare entscheidet, die persönliche Wahl.
• Ich kenne beide Technologien sehr gut. Alle meine Webprojekte werden mit mvc durchgeführt und arbeiten in einem Unternehmen, in dem ich frei entscheiden kann, was der beste Ansatz ist. Ich habe mich immer für MVC entschieden.
• Ich habe mit Webforms begonnen und als ich MVC entdeckte, bin ich dazu gewechselt. Ich weiß nicht ‚, wie jemand Webformulare verteidigen kann. Seitenlebenszyklus und ein Formular für die gesamte Seite? Willst du mich veräppeln? Yahoo Sitebuilder war wahrscheinlich der beabsichtigte Kunde dafür, aber selbst sie wollten ‚ diesen Müll nicht.

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 die manuelle Bindungsbindung überflüssig. Dadurch 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 entspricht der Architektur des Webs genauer. Webforms führt den Status und die Fehler ein Sie haben damit den ViewState eingeführt. 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 eine ganze Seite geladen wird. MVC macht Ajax mit JQuery so viel besser, einfacher und effizienter.
• Weil Sie mehrere Formulare auf einer Seite haben können und weil die Architektur so ist Durch Aufrufe von URLs können Sie funky Dinge wie Ajax tun, indem Sie mit JQuery ein anderes Formular wie ein Bearbeitungsformular in Ihre aktuelle Seite laden. Sobald Sie erkennen, was Sie damit tun können, können Sie ganz einfach 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 als nötig damit. In vielen Fällen konnte man tatsächlich sehen, was falsch lief Aber Sie können nichts dagegen tun. Am Ende führen Sie seltsame Problemumgehungen durch.
• 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 ein halber Arbeitstag.
• Da sich die Webplattform schnell weiterentwickelt, werden WebForms nicht mithalten. Das ist nicht der Fall Wenn Sie sich der neuen Tags oder Funktionen von HTML5 bewusst sind, werden dieselben Inhalte weiterhin gerendert, es sei denn, Sie erhalten (häufig) teure Steuerelemente von Drittanbietern oder warten, bis Microsoft ein Update veröffentlicht.
• 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.

Kommentare

• +1 für Aufzeigen mehrerer Formen. Außerdem ist die Tatsache, dass die HTML-Webformulare generiert werden, die meiste Zeit nicht sehr SEO-freundlich (wie in: große Teile des Ansichtszustands oben auf der Seite).
• Ich muss dieser Antwort zu 100% zustimmen. Letztendlich macht es WebForms so viel schwieriger, Dinge auf der Clientseite (HTML / Browser) zu erledigen. Sie müssen buchstäblich gegen den Rahmen kämpfen, um etwas zu erledigen. Eine aspx-Seite enthält aufgrund von Serversteuerelementen so viel mehr Code als eine cshtml-Seite normalerweise. @ šljaker Wenn Sie ViewState deaktivieren und Serversteuerelemente vermeiden, haben Sie ‚ zu diesem Zeitpunkt viele WebForms aufgegeben. Ich sehe ‚ dieses Argument nicht als besonders überzeugend an.
• Sie können einfache HTML-Steuerelemente in WebForms verwenden, niemand zwingt Sie, Serversteuerelemente zu verwenden. Sie können ein vollständiges zustandsloses Webformular haben, und niemand zwingt Sie, ViewState zu verwenden. Sie können Ajax und jQuery in Webforms vollständig verwenden. Niemand hindert Sie daran, jQuery zu verwenden. Sie können das URL-Routing implementieren. Niemand zwingt Sie dazu, eine statische Dateibasis-URL zu verwenden. 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: Wenn Sie ‚ keine Serversteuerelemente, ViewState usw. verwenden, warum sollten Sie WebForms überhaupt verwenden, wenn MVC ist näher an dem, was Sie ‚ tun? ‚ ist so, als würde man einen Traktor zur Arbeit fahren, aber kein Gelände fahren oder die Schaufel / Hacke oder Stabilisatoren verwenden. Warum nicht einfach ein Auto benutzen?
• @Tjaart Es ist nicht ganz richtig, dass Sie nicht mehrere Formulare auf der ASPNET-Seite haben können.Sie können auf der ASPNET-Seite so viele Formulare haben, wie Sie möchten, aber Sie können nur ein Serverformular haben – Formular mit runat = “ Server “ Attribut.

Ich habe Scott Guthrie , ein MVC-Experte 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 Ich finde es großartig. Deshalb investieren wir in beides. „

Für mich bedeutet dies, dass es kein technisches Problem ist. 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.

Vielen Dank für alle Antworten.

Kommentare

• Scott Guthrie hat erfunden 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 😉
• 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 ‚ nicht in MVC durchgeführt werden könnte, Silverlight wäre der Fallback. ‚ Nehmen Sie dies nicht als negativen Kommentar zu WebForms. 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.
• “ Scott Guthrie hat das MVC-Framework für ASP erfunden .NET während eines Fluges “ Ich denke, das trivialisiert MVC wirklich. Ich kenne Scott Guthrie nicht ‚, aber ‚ bin bereit zu wetten, dass er überlegt hat, wie MVC in ASP.NET implementiert werden könnte für eine Weile und nutzte diesen langen Flug, um einen Bare-Bones-Prototyp als Proof of Concept zu implementieren.
• “ Deshalb investieren wir in beide. “ Und wenn wir feststellen, dass Webformulare abnehmen, werden wir sie gnadenlos fallen lassen, da die Investition in ein letztendlich totes Produkt nicht in unserem besten Geschäftsinteresse liegt.
• Bis Es wird nicht mehr an Schulen unterrichtet, es wird viele Jahre lang immer in der Geschäftswelt anwendbar sein. Colleges und High Schools bieten weiterhin Einführungs- und Fortgeschrittenenkurse in vb.net an. Es geht nirgendwo hin !!!

Dies ist eine veraltete Frage mit vielen Antworten, aber keine hatte die Antwort, von der ich erwartet hätte, dass sie aufgelistet wird.

Die kurze Antwort lautet:

• Verwenden Sie ASP.NET MVC, wenn Sie beabsichtigen, eine Webanwendung mit moderner Programmierung ordnungsgemäß zu erstellen Konventionen und branchenübliche Muster für die ASP.NET-Plattform. 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 eine GUI -zentrierte RAD (Rapid Application Development) , Drag-and-Drop-Ansatz für das sehr schnelle Prototyping von Objekten, dh das Verhalten von Drucktasten / Datengittern, das innerhalb von 15 Minuten verkabelt wird, und die Lösung soll nicht von etwas unterstützt werden Entwickler. Oder Verwenden Sie ASP.NET Web Forms, wenn Sie einen Hintergrund in der GUI oder Windows Forms-Entwicklung haben und Ihre Daten übertragen möchten Kenntnisse im Web.

Um dies jedoch richtig zu betrachten, müssen Sie den Verlauf der einzelnen Elemente verstehen.

ASP.NET Web Forms war die Antwort von Microsoft diejenigen, die dynamische Webanwendungen mit Visual Basic 6 Ac erstellt hatten tiveX-Steuerelemente, VB6-DLLs auf dem Server und ASP Classic. Zu dieser Zeit war die Webentwicklung mit diesen Microsoft-Tools ein echtes Chaos. Zusammen mit dem gesamten .NET Framework, das die Ausgabe von Microsoft war und im Wesentlichen auf das Reißbrett zurückging, wie produktive Geschäftsprogrammierung auf dem Windows-Stack durchgeführt werden kann, war ASP.NET Web Forms zu seiner Zeit erstaunlich und schö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 „Form“ (einem Fenster) auch eine Webseite ein Formular ist (genau wie ein Fenster, siehe) , und in diesem Formular können Sie Beschriftungen, Textfelder, Datenraster, Schaltflächen und andere Dinge, an die VB / WinForms-GUI-Entwickler 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 und teilen dem Formular mit, was zu tun ist, wenn Sie darauf klicken „Ereignis passiert. Genau so haben Windows-GUI-Entwickler Software mit den GUI -Tools von VB6 und konkurrierenden Tools erstellt. außer jetzt wird der Code auf dem Server ausgeführt! Wow!

Dies war die Technologie von 2002. Erstaunlich und schön zu seiner Zeit als Antwort auf das Internet -enabled GUI -Lösungen für die RAD -Entwicklung brachte es ein Gefühl von Macht In einer chaotischen 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 der erforderlichen Implementierungsdetails mit sich bringt , all das belastende Gepäck nec Dies ist wichtig, um den Lebenszyklen der Ereignisse Rechnung zu tragen und die hässlichen Details des einfachen HTML- und Skript-Skripts, das diese Drag-and-Drop-Komponenten und Steuerelemente ausgeben würden, zu verbergen. 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. Auf HTTP, HTML, Javascript und CSS befinden sich 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 Problem mehr, konzentrieren Sie sich nur auf Geschäftsziele und Best Practices für Software.

In diesem Fall bedeutet dies wirklich:

1. Trennung von Bedenken . Beispielsweise muss eine Datenkomponente nicht wissen, wie ihre Daten gerendert werden sollen, und das Ansichts-Markup darf auch nicht mit Details zur Konfiguration der Datenbankverbindung belastet sein. Auf diese Weise kann sich ein Entwickler beim Bearbeiten und auf seinen Problembereich konzentrieren Testcode.
2. Offenlegung und vollständige 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 , diese Details zu verwalten. Tatsächlich ist dies eine Notwendigkeit. Der Vorteil hierbei ist, dass der Entwickler die saubere Semantik von HTML, CSS und Skript erneut schätzen und damit und nicht dagegen arbeiten kann.
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 waren und sich die gesamte Entwicklungsausgabe um Seitenformulare und deren Ereignislebenszyklen drehte, wobei die Logik von Geschäftslogik und Präsentationslogik eng miteinander verflochten war / li>

Beachten Sie, dass HTML bereits eine Markup-Sprache auf sehr hoher Ebene ist, ebenso wie Javascript eine Programmiersprache auf hoher Ebene. 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 Organisation der Front-End-Details von zu ermöglichen den „Ansicht“ -Teil ihrer Lösungen und nutzen Sie die reichhaltige Grundlage, die der Rest der Branche auf der Front-End-Client-Plattform aufgebaut hat.

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 nicht der Fall.NET Web Forms, da Web Forms nicht möchte, dass Sie sich HTML oder Skript überhaupt ansehen, es sei denn, Sie müssen wirklich . In diesem Fall ist Vorsicht geboten, es ist nichts für schwache Nerven

Kommentare

• Dies ist eine gute Antwort, aber # 1 und # 2 sind falsch (WF erfordert keine Komponente, um zu wissen, wo ihre Daten sind kommt von, es ist eine Option und Sie haben Ihren ASPX-Dateien immer HTML hinzugefügt, um die Asp-Tags zu unterstützen, die Sie rendern. Sie mussten nie tief graben und die Steuerelemente bekämpfen, es sei denn, Sie haben versucht, auf eine ASP-Funktion zuzugreifen, die nicht für Entwickler gedacht ist Interaktion. Die großen Punkte sind Testbarkeit und Entwurfsmuster.)

Ich bin ein vollständiger und vollständiger Konverter 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, wenn Sie eine schwere Lebensdauer haben mit Gittern zu tun haben. Die Rastersteuerelemente sind wirklich sehr hilfreich, wenn Sie über ein einfaches Dataset verfügen, 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 für mich; aber wie Ryan betonte, kann WebForms ein großes Chaos sein, weil Sie beide Seiten spielen des Zauns aus einer raffinierten Code-Behind-Datei. Es kann gleichzeitig eine Rose und ein Dorn sein, um all Ihre Controller-artigen Inhalte 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 Ablauf Ihrer App steuern möchten, ist dies definitiv der richtige Weg. Es ist etwas gewöhnungsbedürftig Zunächst aber ich denke, es ist die bessere Option für Greenfield-Apps.

Zusammenfassend kommt es für mich auf Grids und! Grids an. 🙂

Kommentare

• +1 für das schöne Bild, das mit “ auf beiden Seiten des Spiels geliefert wird Zaun aus einer raffinierten Code-Behind-Datei „.
• Sehr hilfreich. Ich ‚ mache eine sehr schwere gitterbasierte App und ich ‚ habe Silverlight, xbap ausgeschlossen und es lag an einer Show dazwischen diese beiden.

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.

Danach In 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 etwa 1/2 Tag genau so fertigstellen, wie ich es wollte.

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

Kommentare

• @JimG – Uhh Alles, was dazu führt, dass eine Person Datensätze ohne interessante Assoziationen in eine Datenbank eingibt und diese Person oder eine andere Person sie an einem anderen Punkt lesen / drucken lässt, kann im Grunde genommen mithilfe eines MVC-Frameworks gerüstet werden. Zugegeben, das ist nicht ‚ die meisten Apps, aber ‚ ist viel mehr als Sie mit Forms tun können. Ich denke, Ihr -1 beweist meinen Standpunkt.
• Das ‚ ist 1/4 eines Tages.
• Aber wenn die Anforderungen gleich sind “ Ich benötige eine App mit zwei Rollen, eine zum Aufzeichnen einiger Informationen, die andere zum Anzeigen und

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 auf einer Seite ein Geschwindigkeitsproblem habe, ein wirklich gutes Buch über asp.net Geschwindigkeit ist praktisch (Rick Kiessig ist der Mann).

Webformulare sind für Ex-Windows-Leute mvc ist für Web-Leute

, aber in der modernen Welt, in der Rick ein großartiges Buch geschrieben hat Mit Servern, deren Geschwindigkeit täglich zunimmt, und billigen Codierern in Indien, haben Webformulare den Vorteil, dass

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

Ich denke, das Abstrahieren von REST ist schlecht, das gesamte Postback-Modell ist schlecht, die Art und Weise, wie HTML / CSS mit Vertrauen übergeben wird im GUI-Editor ist schlecht, die Betonung auf Dinge wie Assistenten und GUIs zum Einrichten ist schlecht, die URLs sind schlecht.

Kommentare

• Könnten Sie genauer erklären, warum Sie so denken?
• Ich denke, das Abstrahieren von REST ist zurück, das gesamte Postback-Modell ist zurück, die Art und Weise, wie HTML / CSS mit dem GUI-Editor übergeben wird, ist schlecht , die Betonung auf Dinge wie Assistenten und GUIs zum Einrichten von Dingen ist schlecht, die URLs sind schlecht usw. usw.

Ich habe diese Überlegung unter den 15 vorhandenen Antworten auf diesen Thread noch nicht gesehen, aber ich denke es 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 seine Microsoft-Gegenstücke; Daher kann die Wahl der MVC natürlich durch die Erfahrung des Teams in diesen Bereichen sowie durch die in anderen Antworten angegebenen Faktoren beeinflusst werden.

Kommentare

• + 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 dieser Muster führt zu einer besseren Einhaltung der SOLID-Prinzipien, was sich in einer insgesamt besseren Wartbarkeit niederschlägt. Diese bewährten Techniken sind auch der eigentliche Schlüssel zur Wiederverwendbarkeit.

Unser Grund, nicht zu gehen Für MVC war es vor einigen Jahren eine unausgereifte Technologie von Microsoft. 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 etabliert hat und wir über die Infrastruktur verfügen, um dies zu unterstützen.

Kommentare

• Würde es Ihnen etwas ausmachen, einige dieser Funktionen aufzulisten, für die Windows Server 2012 erforderlich ist?

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

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

Ist nicht der eine besser als der andere, haben einfach beide Ansätze oder Frameworks 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,

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 zu verwenden und if / for-Schleifen anstelle von Modellbindung und serverseitigen Steuerelementen.

Handelt es sich um WebForms oder MVC-Code:

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

Die einzige Einschränkung, die ich in WebForms gefunden habe, besteht darin, dass Sie Dependency Injection / Inversion of verwenden Kontrolle, Sie können keine Konstruktorinjektion haben, da WebForms-Seiten einen parameterlosen Konstruktor haben müssen, also müssen Sie die Eigenschaftsinjektion verwenden. Ist das wirklich eine so 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.

ASP.NET-Webformulare bietet Ihnen viel Kontrolle über den Client von der Serverseite mit direktem Zugriff zu so ziemlich allem. Im Wesentlichen sind Ihre Ansicht und Ihr Controller ein und dasselbe, was Ihnen viel Leistung und meistens viel Chaos verleiht.

ASP.NET MVC trennt die Ansicht und den Controller, indem die enge Kopplung von getrennt wird eine ASPX-Datei und die ASPX-CS-Datei, die sie in Webformularen begleiten.

Der Unterschied besteht im Wesentlichen darin, dass Sie viel mehr (normalerweise alle) Verarbeitungsvorgänge ausführen, um Daten anzuzeigen Sie können die Geschäftslogik und den Rest in der Steuerung belassen und beide gemäß Konvention sauberer halten, aber auch mit weniger Zugriff aufeinander, als es Webformulare zulassen.

Kommentare

• WANN sollten Webformulare gegenüber MVC bevorzugt werden? Dies beantwortet nicht die ursprüngliche Posterfrage.
• @WeekendWarrior – Wenn Sie mehr serverseitigen Zugriff auf den Client wünschen, wählen Sie Webformulare. Wenn Sie den Client / Server in Ihrem Code stärker entkoppeln möchten, wählen Sie MVC. Am Ende des Tages machen beide genau das Gleiche. Umleitungsfilter machen dasselbe wie die MVC-URLs, und Sie können Webforms-Code in eine separate mittlere Ebene verschieben, um ihn weiter zu entkoppeln. weblogs.asp.net/scottgu/archive/2010/01/24/…
• In Bezug auf Ihren dritten Punkt landet diese Geschäftslogik in der Datei .aspx.cs – ich denke, dies ist die Schuld der Entwickler. Es ‚ ist nicht / soll / da sein. In Webforms ist die ASPX die Ansicht “ „, die ASPX.cs die “ controller “ äquivalent, um den Code zu verarbeiten, der sich nur direkt auf die Benutzeroberfläche bezieht, indem eine Geschäftsschicht oder eine grobkörnige Geschäftsfassadenschicht abgefragt wird. Die Tatsache, dass Leute Geschäftslogik in die .aspx.cs einfügen, ist nur eine schlechte Programmierung. Sie könnten auch die Geschäftslogik in MVC richtig in die Sicht bringen! MVC erzwingt ‚ keine Trennung dieser Dinge.
• Im Wesentlichen hat er mehr Recht als andere hier veröffentlichte Antworten. ASP.net ist die Grundidee einer von Microsoft entwickelten modularen Webtechnologiefamilie. Das ASP.net MVC-Modul mag ein zeitlicher Hype sein, aber es ist sicher nicht das letzte, alles beginnt mit ASP.net. Wenn Sie also ASP.net wählen, wenn Sie nicht glauben, dass MVC nicht Ihr Ding ist, sind Sie vielleicht mehr in etwas sonst OWIN oder …, etwas Fortgeschritteneres oder einen eigenen Rahmen für Ihre Aufgaben. Möglicherweise benötigen Sie nicht einmal ASP.MVC und überspringen es und gehen zu Owin oder Katana, aber bis Sie dort asp verwenden.net

Meiner Meinung nach sind sie verwandt genug und haben ungefähr die gleichen Fähigkeiten, die es geben sollte

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.

Es handelt sich nicht um vollständig getrennte Einheiten. Solange Microsoft beide unterstützt, werden Sie meiner Meinung nach weiterhin eine gemischte Gruppe außergewöhnlicher Entwickler sehen.

Hier geht es um persönliche Entscheidungen, 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 des simplen Ansatzes nicht die Zeit nehmen, die enormen Funktionen des WebForms 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 , dass WebForms „t. Tatsächlich haben das Aufkommen von jQuery und die Zusammenarbeit mit WebForms (sowie MVC) diese Argumente weniger problematisch gemacht. Und wenn die Leute über die Trennung von Bedenken als Vorteil sprechen, den MVC gegenüber MVP hat, frage ich sie, wie viel Sie wissen über objektorientierte Programmierung Bescheid und wissen, wie sehr 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 ist es soweit Für Sie bleibt jedoch die Wahrheit, dass sich nicht jeder Zeit nimmt, um eingehend zu lernen, wozu eine bestimmte Technologie in der Lage ist.

Kommentare

• Das Gleiche gilt für Die enormen Fähigkeiten von Webformularen. Die meisten Leute sehen die Trainingsräder von Webformularen und vergleichen diese mit MVC.
• Es macht heutzutage wenig Sinn, eine Abstraktion über HTML und Javascript zu lernen (auch in) 2013). Es ‚ wird Ihnen für Ihre zukünftigen Möglichkeiten nicht gut tun. HTML und Javas Cript ist in Ordnung so wie es ist. Es zu bekämpfen ist ein verlorener Kampf.

Wenn ich mit einem Programmierproblem konfrontiert bin, schaue ich oft ins Internet für 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 es mit Webforms nicht funktioniert. Im Moment bleibe ich also bei Webforms, bis MVC so ausgereift ist, dass es ersetzt werden kann.

Nun, WebForms verfügen über mehr Lernressourcen (einfach aufgrund der Tatsache, dass es älter ist), und daher werden neue Programmierer, die nicht „wissen“, eher finden Informationen zu dieser älteren Technologie im Gegensatz zu neueren Produkten wie MVC.

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

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

Es gibt also einige logistische Probleme: Überwiegen die Vorteile von MVC die Kosten in Bezug auf geringere Qualität und Bereitstellungszeit? 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 von einem früheren Kommentator angegeben, verhindert MVC auch, dass Sie die gleiche Ebene der Benutzeroberfläche erreichen den Controller, wie Sie es mit WebForms könnten. 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 schwierig sein, ein Programm bereitzustellen / zu implementieren, das sich fanatisch an dieses Paradigma für alles hält, was sie schreiben. P. >

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

• Webformulare können die von MVC verwendete Routing-Engine (oder etwas sehr Ähnliches) 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 Präferenz an und / oder was das Projekt ist. Beide verfolgen einen deutlich unterschiedlichen Entwicklungsansatz. Persönlich habe ich daran gearbeitet, auf MVC umzusteigen, aber ich arbeite immer noch gerne mit Webforms. Ich denke, die Antwort darauf, ob Sie MVC oder Webforms verwenden sollten, liegt in Ihrer Entscheidung, beide Technologien kennenzulernen.

Kommentare

• Webforms und MVC empfehlen standardmäßig eine radikal andere Einstellung für die Webentwicklung. Dies ist wichtig , nur wenige Entwickler weichen davon ab von “ die Standardeinstellung „. Beide können jedoch verwendet werden, um dasselbe zu erreichen.