Können serverseitige Viewstates eines der größten Probleme mit ASP.NET beheben?

Question

Ich habe ein paar SO-Artikel darüber gelesen, ob ASP.NET MVC die Migration von "normalem" ASP.NET lohnt. Einer der größten Gründe für die Verwendung von MVC, den ich gesehen habe, war, Viewstates nicht verwenden zu müssen.

Es ist jedoch möglich, Viewstates durch Speichern der Viewstate-Informationen auf dem Server zu beseitigen, wie this article zeigt. Ich habe es in einem Beispielprojekt versucht, es funktioniert großartig, ist völlig transparent, soweit ich es bemerkt habe und war sehr einfach zu implementieren.

Also, wo ist der Haken? Ich erwarte, dass es den Server etwas belastet, aber kann es wirklich so schlimm sein? Wenn nicht, warum verwenden nicht mehr Menschen diesen Ansatz, anstatt sich über Viewstates zu beschweren?

Answer 1

Das einzige Problem mit Viewstate missbrauchen die Verwendung von es. Dies geschieht leicht, da standardmäßig alle aktiviert sind. Sie können es nicht standardmäßig auf einer Seite ausschalten und bestimmte Steuerelemente selektiv aktivieren (sie werden dies auf der Version 4.0 unterstützen). Sie werden wenig Code mit dem viewstate = false sehen, und mit Listen von Informationen kann es sehr schnell werden.

Es gibt sogar einige Kontrollen von Drittanbietern, die es schrecklich missbrauchen. Ich musste helfen herauszufinden, warum eine Seite furchtbar langsam war (da es nicht einmal funktioniert), und es stellte sich heraus, dass die Menge der heruntergeladenen Informationen riesig war, die Ursache war, dass der View-Status mehr als 10 mal so groß war wie der Inhalt (wirklich) und es war eine Kontrolle von Drittanbietern, die es liebte, alles zu speichern, was man ihr reichte (was wirklich hässlich wurde, weil es eine Hierarchie von Objekten bekam).

Also das eigentliche Problem ist nicht der Viewstate, es ist seine Größe. Wenn Sie bereits das Problem der großen Viewstates haben (normal groß, nicht extrem von oben), dann bedeutet das Verschieben zu einer Sitzung auf dem Server, dass Sie eine große Menge an Informationen speichern. Dies verschiebt das Problem von einem Ort zum anderen und mildert möglicherweise einige seiner Effekte, aber es adressiert nicht das wirkliche Problem, indem es zu viel unnötigen Zustand speichert (weil entweder die Entwickler oder etwas Dritter sich schlecht benommen haben).

Das sagte, ich glaube nicht, dass ich es das einzige Hauptproblem mit dem regulären asp.net Ansatz nennen würde. Nimm das nicht als "entwickle dich nicht damit", sondern eher wie "wenn du dich darauf entwickelst, lerne es wirklich gut kennen". Ich arbeite viel mit regulären asp.net, es kann arbeiten und sehr gut. Wenn ich an dieser Stelle beginnen würde, denke ich, dass ich mit asp.net mvc gehen würde, da ich denke, dass reguläres asp.net viel mehr vom Entwickler braucht, um es richtig zu machen.

Answer 2

Je größer Ihr Projekt wird und/oder je mehr Menschen Sie verwenden, desto geringer kann der Effekt auf Ihre Leistung werden.

Answer 3

Um ehrlich zu sein, die meiste Zeit können Sie den Viewstate nach unten schneiden - viele Entwickler, mich eingeschlossen, gehen Sie nicht durch alle Kontrollen, die es nicht brauchen und deaktivieren Sie es - ich neige dazu, dass ich nur Viewstates für Sachen wie Datagrids, die meisten anderen Kontrollen funktionieren gut, aber wie gesagt, ich mache es nicht so oft wie ich sollte.

Answer 4

Ich stimme eher nicht mit der Aussage überein, dass beim Wechsel zu ASP.NET MVC der Viewstate entfernt wird. Die Verwendung von ViewState oder eine andere Verwendung ist bei der Entscheidung, ob zu ASP.NET MVC gewechselt werden soll, von geringerer Bedeutung. Wichtiger ist die Trennung, die Sie zwischen Ihrem Modell (den Typen, die Ihren Problembereich definieren), Ihren Controllern (dem Code, der beschreibt, wie Benutzer mit Ihrer Site interagieren) und Ihren Ansichten (der Rendering-Logik, die HTML generiert oder was auch immer Sie möchten) .

In Bezug auf das Einbringen von ViewState in Ihren Server könnte dies ein Skalierbarkeits-Flaschenhals werden - wenn Sie eine Multi-Webserver-Site hätten, müssten Sie auf diesen View-Status von all diesen Servern zugreifen können.Sie müssen sich dann darum kümmern, diesen Viewstatus zu löschen - wenn er in die Seite eingebettet ist, gibt es nichts zu beachten, aber wenn er auf dem Server gespeichert ist, wie lange sollte dann der Viewstatus einer Seite beibehalten werden? Der Grund dafür, dass viewstate existiert, besteht darin, den "web forms" -Ansatz für die Web-Entwicklung zu unterstützen, bei dem eine Seite zum Server zurücksendet, um sich selbst zu aktualisieren.

Es ist diese Herangehensweise an die Web-Entwicklung, anstatt sich selbst zu betrachten, von der ich glaube, dass sie die meisten Menschen vermeiden wollen. Stateless Markup, plus AJAX-Updates, wo erforderlich, macht eine viel sauberere Anwendung und eine, wo Dinge wie Ausgabe-Caching viel einfacher angewendet werden können.