Letzte Woche bat mein Chef mein Team, ASP.NET MVC für das nächste Projekt zu bewerten. Alle von uns arbeiten mit Webform seit .NET 1.1, wir haben noch keine MVC Erfahrung, aber alle meine Kollegen sind interessiert an ASP.NET MVC, Aber kein Glück, unsere endgültige Antwort ist NEIN.
Weil:
Wir glauben, obwohl Sie ASP.NET Guru sind, können Sie eine komplexe Anwendung in kurzer Zeit erstellen. Aber wenn Sie zu ASP.NET MVC wechseln, wird die Entwicklungszeit länger dauern, müssen alle Dinge mit HTML-Helfer, keine Web-Kontrolle und viele Fragen, öffnen Sie die Firefox-Registerkarte mit ASP.NET-Forum für Fragen zu stellen.
Wir hatten viele Male gesehen, dass Leute sagen, dass MVC ein besseres Projektmanagement bietet, aber wenn es eine komplexe Website ist, kann ich mir vorstellen, dass es hundert & lt;% =% & gt; TAGs auf einer Seite, und offen Controller zu sehen, was Sie zurückgeben, und öffnen Sie das Modell, um die Logik zu sehen.
Ich kann sagen, MVC ist nicht schlecht, aber Webform ist stark genug, um den Job zu bewältigen.
Es wird einige Wochen dauern, um zu einer neuen Technologie oder "Denkweise" zu wechseln.
Mit MVC müssen Sie von der alten ASP.NET Forms-Denkweise "komplexe Webanwendung" wegkommen, in der "wie viele Seiten wir haben, über 300 Seiten! das wäre riesig!". Sie ändern die Ansicht Ihrer gesamten Anwendung. Du wechselst von der alten Denkweise von "Welche Seite muss man als nächstes erschaffen" zu der MVC-Denkweise, "welche Funktion wir als nächstes implementieren müssen".
Zum Beispiel habe ich selbst die Kontrolle über ein Projekt übernommen, das allein im "Web" -Projekt mehr als 3300 Dateien hat (plus die 11 unterstützenden Assemblies). Eine Sache, die ich entwerfe, ist, wie MVC die Anzahl der physischen Dateien drastisch auf etwa 310 reduzieren wird. Wie? Weil ich mich von "Hier ist eine Seite" wegbewegt. Hier ist eine andere Seite. " zu einer "hier ist die Funktion, die ich implementieren möchte" Art zu denken.
Wenn Sie Seiten als die Funktion betrachten, die Sie erreichen möchten, beginnen Sie stattdessen, Teile dieser Seite in allgemeine Funktionen zu zerlegen.
MVC kann mit dieser Denkweise stark skalieren, denn jetzt haben Sie eine Vorlage für die von Ihnen gewünschte Art und Weise. Sie müssen lediglich eine andere "Funktion" implementieren, um das Aussehen der gewünschten Ansicht (html) zu ändern rendern. Keine zweite Seite, keine zusätzlichen Steuerelemente usw.
Was "no web controls" betrifft, wie Sie bereits erwähnt haben: Dies erfordert wiederum eine andere Art zu denken. Es gibt den HtmlHelper, der für das grundlegende Rendering und die Codierung verwendet wird. Ich benutze das gleiche Konzept mit einer abstrahierten Klasse namens MyProjectHelper, die meine "Funktionen" auf der Seite rendert (functions = code).
Zum Beispiel habe ich in der Vergangenheit immer ein Server Control für meine DisplayNames erstellt. Dies erlaubte mir, die Art und Weise zu kontrollieren, in der DisplayName angezeigt wurde, insbesondere mit einem Wechsel zu Facebook Connect und anderen Dingen. Mit MVC verwende ich nicht mehr eine "Serversteuerung", sondern eine "Funktion" in einem ViewModel, um diesen Text zu rendern: CollegeProjectViewModel.RenderDisplayName (). Da dies nur ein Teil des UI-Layers ist, rendert dies den Anker nach Bedarf mit allen gewünschten Optionen (natürlich wird das Abstract vom CollegeProjectViewModel geerbt, das das "einfache" Text-Rendering annimmt).
MVCs Stärke liegt in der Fähigkeit, nicht länger eine "Webseite" zu benötigen, sondern "Funktionen" oder Methoden, was Sie mit Ihrer Site machen wollen. Wenn Sie auf diese Art zu denken umsteigen, können Sie wirklich mit so vielen Methoden skalieren, die Sie auf Ihren Controllern erstellen. Es beschleunigt wirklich Dinge auf einer Massen-IMO.
Ich habe 6 Monate lang an meinem letzten Unternehmen an einem MVC-Projekt gearbeitet (wir haben die CTP-Builds und schließlich die Beta-Builds verwendet). Anfangs war es lustig und aufregend und es fühlte sich an, als wären wir wirklich auf etwas konzentriert. Wie viele andere .NET-Entwickler waren wir von den undichten Abstraktionen von Web Forms müde.
Im Laufe der Zeit begannen wir jedoch, unsere Entscheidung in Frage zu stellen. Die UI-Entwicklung benötigte ungefähr 80% unserer Zeit. Wir mussten unsere gesamte Benutzeroberfläche von Grund auf neu erstellen. Die Hälfte der Zeit schien es, als ob wir das Rad neu erfinden würden. Die meisten unserer Rich-UI stammten von JQuery, kombiniert mit benutzerdefinierten HTML-Hilfeprogrammen, die zwar Spaß beim Entwerfen, aber auch zeitaufwendig waren.
Es gab andere Probleme, denen wir begegneten, wie die Notwendigkeit, DTO-ähnliche Objekte aus unseren Geschäftsobjekten (die von einem von NHibernate unterstützten Repository abgerufen wurden) auf die Ansichten zu mappen. Und unsere Controller, die angeblich leicht und wartungsfreundlich sein sollten, wurden zunehmend unübersichtlich und wir diskutierten ständig über den richtigen Weg zur Implementierung der Controller-Vererbung.
Rückblickend denke ich, dass all unsere Probleme auf unseren Mangel an Erfahrung und Verständnis für MVC zurückzuführen sind. Wir alle mochten die Idee von MVC, aber hatten einfach nicht die praktische Erfahrung und das Know-how, um es effektiv zu verwenden, was ich für sehr komplex halte (man denke an etwas wie Sales Force, aber mit besserer Berichterstattung) .
- AKTUALISIEREN -
Ich habe es den letzten Monat benutzt, um an einem sehr kleinen Projekt zu arbeiten und bisher läuft alles reibungslos. Es ist viel einfacher zu arbeiten als die CTP-Versionen, die ich vor einem Jahr benutzt habe. Ich schaue mir gerade meine eigene Lösung für komplexe "Grid Views" an, und dann könnte ich für die meisten Projekte komplett umschalten. Dynamische Daten haben mich jedoch richtig behandelt und ich bin ein bisschen zwischen den 2 gerissen.
- UPDATE 2011 -
Nach einigen MVC-Projekten verschiedener Größe im Laufe des letzten Jahres bin ich ein wenig konvertiert. Alle tatsächlichen Probleme, die ich damit hatte, wurden meist in den neuesten Versionen (2 & 3) gelöst, insbesondere in denen, die sich mit der Validierung von Modellen und der Bindung an Ansichten befassen.
Eine Sache jedoch: Es kann immer noch etwas mühsam sein, hoch interaktive Datenraster zu erstellen, was in WebForm noch etwas einfacher ist. Es gibt jedoch Angebote von Drittanbietern, die nützliche MVC-Erweiterungen bieten, die dies weniger wichtig machen. Persönlich nutze ich Teleriks Angebote zu guten Zwecken.
Zu den vielen Vorteilen von MVC gehört das Entfernen des Viewstate-Hogs.
Wenn Ihre Webform-App sehr umfangreich ist und viele serverseitige Elemente verwendet, die Ihre Zeile mit Viewstate aufblähen, kann MVC Ihnen tatsächlich helfen, auch wenn die Entwicklung länger dauern kann.
Auf der anderen Seite sollten Sie nach .NET v4.0 Ausschau halten, mit dem Sie viewstate auf der Steuerungsebene und nicht nur auf Seitenebene steuern können. Das wird MVC insgesamt noch schmackhafter machen.
Ich denke, Sie haben Recht, dass Ihr Team Zeit braucht, um sich an die neue Technologie anzupassen, und das wird kurzfristig zusätzliche Zeit erfordern.
Ich würde MVC nicht in der Produktion verwenden, bis einige anständige Bücher herauskommen und das Team eine Chance hatte, die Bücher zu lesen und mit der Technologie zu spielen. Sonst scheint dein Entwicklerteam viel Zeit damit zu verbringen, Screencasts zu schauen und nach Dokumentationen zu fischen.
Ich kam von Webform-Entwicklung (genau wie Sie), von 1.0 bis 3.5. Als ich MVC (CTP) entdeckte, brauchte ich etwa 6 Monate, um meine Kollegen (und meinen Chef) davon zu überzeugen, dass es der richtige Weg ist.
Einige der Highlights meiner Argumente:
Obwohl # 6 ein wenig subjektiv ist, habe ich versucht, es durch den Bau von Prototypen zu beweisen. Für meinen Prototyp habe ich eine einfache Dashboard-Web-App erstellt, die sowohl webform als auch asp.net mvc verwendet. Ich habe meinen Kollegen und meinem Chef das Ergebnis sowie die Komplexität des Aufbaus und der Wartung jedes einzelnen gezeigt. Am Ende migrieren wir unsere Hauptmethodik von Webform zu MVC.
Es stimmt, dass es eine Weile dauert, ein Webform-Paradigma zu "verlernen". Aber sobald Sie es bekommen, ist MVC so viel einfacher zu erlernen und Sie können damit laufen.
Im Webformular ist es zwar leistungsfähig, aber oft verbringen wir in großen Projekten viel Zeit damit, ein Server-Steuerelement so zu "anpassen" oder zu "zwingen", dass es sich so verhält und ausführt, wie wir es wollen des Systems steigt die Komplexität dieser Anpassung exponentiell an.
TRUE AJAX ist auch im Webformular ziemlich schwierig. UpdatePanel hat seine Rolle, aber verschachtelte Update-Panels haben auch einen eigenen Anteil an Problemen.
Für mich und meine Kollegen läuft es auf die Möglichkeit hinaus, unseren HTML / Code / AJAX zu kontrollieren - anstatt automatisch 90% vom Framework zu generieren, aber wir müssen viel Zeit und Mühe aufwenden, um den Rest von 10% zu bekommen .
ASP.NET MVC, kombiniert mit jQuery und Ihrem bevorzugten biz Tier-Framework oder ORM, ist extrem leistungsstark. Bisher haben wir 3 Produktions-Releases mit ASP.NET MVC veröffentlicht, die alle gut funktionieren - hucke mal stackoverflow.com (es benutzt MVC btw).
Tags und Links asp.net-mvc webforms