Warum sollten Sie MVC über Webformen verwenden?

Question

Kürzlich beschrieb ein Architekt unser Unternehmen als eine Rolls-Royce-Lösung (MVC), als er nur einen Toyota (Webformen) brauchte.

Ich bin gespannt, was Sie über Webformen gegenüber MVC als architektonische Wahl denken.

Answer 1

Die Rolls-Royce/Toyota-Analogie ist furchtbar fehlerhaft und irreführend. Einer (ASP.NET MVC) ist nicht nur eine schickere oder teurere Version des anderen (ASP.NET WebForms). Sie sind sehr unterschiedliche Ansätze zum Erstellen von Webanwendungen mit ASP.NET.

Für mich besteht der größte architektonische Unterschied zwischen MVC und Webformen darin, wie sie mit der staatenlosen Umgebung des Webs zusammenarbeiten: WebForms ist schwierig, eine Reihe von Abstraktionen zu erstellen, die die staatenlose Natur der Webprogrammierung verbergen, während MVC die staatslose Umgebung umfasst und mit funktioniert es.

Jeder Ansatz hat seine Vorteile und Nachteile, aber ich genieße es wirklich, wie das Erstellen von Websites mit MVC viel mehr anfühlt natürlich als Webformen (mit seiner Schicht auf Schicht von undichten Abstraktionen).

Answer 2

Alte Frage, aber es verdient eine detailliertere Antwort, nur für den Fall, dass jemand anderes da draußen noch ein Dilemma darüber hat.

Letztendlich ist WebForms eine dünne Lösung, bei der es bedeutet, dass Sie ein paar hübsche Schaltflächen drücken, und das Front-End-Zeug (Client) ist für Sie erstellt. Wenn Sie Personen haben, die wissen, wie man es in Webformen ausgeht, und es absolut keine Bedenken nach Wartbarkeit/Modifizierbarkeit gibt und die Website völlig kurzfristig und verfügbar ist, ist an diesem Ansatz überhaupt nichts falsch. Es ist möglich zu lernen, wie Sie Ihre eigenen Sachen machen, aber in diesem Fall müsste es sowohl die Web-Stoffe-Webforms .NET-App-Entwickler vor und alle Webforms-Dinge, die die meisten Kunden-Seiten-Webdevs machen, erfordern, die Microsoft zu schützen Ingenieure verantwortlich.

In den 99,5% aller anderen Anwendungsszenarien haben wir nicht mehr versucht, das Web vor App-Entwicklern zu verbergen, da Sie wirklich besser lernen, wie das Web funktioniert, wenn Sie Web-Apps schreiben möchten. Die Ironie dicker und dünner Kundenlösungen ist, dass der Mist unvermeidlich der dünne Klient-Ansatz aus Ihrem vorderen Ende aufblättert und alles andere als Performant ist. Noch wichtiger ist, dass diese Lösungen für Menschen, die tatsächlich wissen, was sie tun, als alle Hölle unflexibel gemacht haben und nicht durch den in Kraft getretenen Rahmen eingeschränkt werden wollen.

Es gibt nichts ganz so sinnlos als jemanden, der alles über CSS, JavaScript, HTML, XHR weiß und sie völlig nutzlos macht, indem sie sie bei jedem Schritt des Weges mit einem Rahmen, der ...

• Löschen Sie alle "unnötigen" Skript -Tags in den Kopf -Tags, um Sie davon abzuhalten, sich von den Abhängigkeiten der Skript zu vermasseln. (Besser zulassen, dass ein "Drehbuchmanager" das für Sie verantwortlich gemacht wird) gewährt, niemand legt sie dort hoch, wenn sie wissen, was sie tun, aber das ist nur durcheinander.

• Besteht darauf, dass Sie das gesamte HTML in ein ginormus Form -Tag wickeln. HTML erlaubt keine Formulare in Formularen, sodass Sie die Webformen oder keine Möglichkeit durchführen.

• Erstellt wie ein 18-stufiger "Lebenszyklus" für das, was wirklich auf UI-Ereignisse reagieren sollte, indem Sie mit dem Browser interagieren, um Nachrichten an den Server zu senden, und dann reagieren, wenn der Server antwortet. Wenn man diesen Prozess mit einem großen riesigen Müllhaufen abstrahiert, musste es nie passieren (und um fair zu sein, ist MS nicht der einzige Esel, der dies versucht hat).

• Eigentlich kann alles, was es kann, um nicht-wirkende Lösungen für Probleme zu verwenden. Beispiel: Als ich ein jüngerer Client-Side-Entwickler war, habe ich einen ganzen Tag damit verbracht, einen Weg zu finden, um am oberen Rand der Seite einen Sendel-Schaltfläche zu erstellen riesige Form). Normalerweise würde dies 5 Minuten dauern, aber nach einigen Stunden Reverse Engineering Die Webformen JavaScript verantwortlich, stellte ich fest, dass sie unter anderem eine Eigenschaft festlegten, von der ich zu diesem Zeitpunkt nicht einmal wusste, was das letzte Formular Element zu haben soll Der Fokus war so, dass bei Klicken mit einer Sub -Schaltfläche nur die offizielle Schaltfläche Offizieller Microsoft -Subjekt (TM) in Bezug auf die Aktivierung eines offiziellen Microsoft -Subulations -Handlers (TM) funktionieren würde.

Also nein, Rolls-Royce gegen Toyota ist völlig unvernünftig. Ich würde mehr sagen, ein absolut vernünftiger Hyundai, den Sie für einen von Microsoft Engineered Pinto mit einem an Bord befindlichen System viel zu viel bezahlen, das automatisch scharfe 90 -Grad -Kurven macht Bequeme Wand zum Einschlagen. Ein ideales Auto für den selbstmeidigen Brand-Loyal-Treiber, der nichts über das Web weiß und Microsoft lebenslange Loyalität schwören möchte.

Alles .NET MVC ist wirklich einfach und vernünftig und erfindet seine eigene Ebene nicht neu, um über das Web zu schlagen. Es funktioniert einfach mit dem, was da ist, um etwas Kesselplatte für Sie auszuschalten. Es gibt bessere/billigere/freie Frameworks, aber wenn Sie sich bereits in das .NET-Ding eingeschlossen haben, könnten Sie viel schlechter machen.

Aber im Ernst, bleib die!@#$ Von Webforms weg. Es ist jetzt fast tot. Lassen Sie es gehen. Sagen Sie Ihren Kunden, dass Sie es für das Dreifache des Geldes tun werden, wenn sie Ihnen auch einen exklusiven und lukrativen Supportvertrag versprechen, wenn sie tatsächlich etwas Neues oder anderes tun möchten oder wenn Mist brechen, weil nicht einmal MS könnte Seien Sie die Mühe, weiterhin zu diesem Gentre einer 10.000 -Zeile -Ajax.js -Datei hinzuzufügen, die sie aus ihrem DLL -Arsch herausziehen, wo Sie sie nicht berühren können.

Answer 3

Eine ASP.NET -MVC -Lösung muss nicht komplizierter sein als eine WebForms -Lösung. Persönlich finde ich, dass ASP.NET MVC tatsächlich viel einfacher ist als Webformen, und es scheint definitiv von Natur aus sauberer zu sein.

Nach meiner Erfahrung haben viele der MVC -Frameworks (ASP.NET, Rails, Codesigniter usw.) viel von den gleichen Kernfunktionen und -konventionen. WebForms ist wirklich die ungerade Ente aus einer Web -Sicht. Meine Vermutung ist, dass die meisten Webprogrammierer viel schneller bei der Aufnahme von ASP.NET MVC als Webforms sind.

Answer 4

Der wichtigste Grund, warum Sie ASP.NET MVC über ASP.NET WebForms verwenden würden, ist die Testbarkeit. Natürlich können Sie Webforms für Unit -Tests ausführen, dies erfordert jedoch verspottete Frameworks und viel Schmerzen. Der zweite Grund ist, dass MVC es ein bisschen macht Einfacher Bedenken trennen. Dies kann eine große Wiederverwendung von Code liefern und Ihren Code locker gekoppelt machen. Dies bedeutet nicht, dass es unmöglich ist, dasselbe in ASP.NET mit Mustern wie MVP zu tun.

Der Nachteil von MVC ist, dass Sie einen Großteil der Funktionalität verlieren und das in den letzten zehn Jahren in Webformen integriert wurde (fast). MVC hat seit seiner Gründung einen langen Weg zurückgelegt, um ähnliche Merkmale zu ermöglichen.

Hat jemand in der einen oder anderen Weise Beweise von der Tech "schneller" beweist?

Ich denke nicht, dass einer besser ist als der andere. Ich mag das MVC -Framework sehr und habe es mit großem Erfolg verwendet, aber ich stelle immer sicher, dass ich die Technologie wähle, die dem Projekt entspricht.