ViewState - Warum nicht Server-sided?

Hallo community

Ich wundere mich etwas weshalb der ViewState bei ASP.NET Applikationen Client-sided persistiert wird und nicht Server-sided. Dadurch gibt es ja einfach unnötig viel overhead.

Was ist der Grund zu diesem Designentscheid?

Gruss

Samuel

Man kann ja auch mit mehreren tabs auf der selben Seite unterwegs sein, und so würde es dabei zu Problemen kommen

Nja, dieses Problem liese sich lösen wenn man einfach eine Objekt ID in ein hidden field setzt. So könnten server-sided persistierte Objekte den einzelnen Requests zugeordnet werden...

Zudem weiß der Server nie, wie lange die Zeitspanne zwischen zwei Requests ist; er würde sie also "unendlich" lange vorhalten.
Sollen diese Daten nur während einer Session verfügbar sein, so nutzt man eben auch die Session.

Der ViewState beinhaltet aber vor allem Daten aus, zb einer Form; keine "aktiven Daten".

Aus diesem Grund ist ASP.NET WebForms auch nicht für Anwendungen für Mobile Devices geeignet. Hierfür gibt es die deutlich moderne Plattform "ASP.NET MVC", die den Fokus auf moderne RIAs hat; hier gibt es auch keinen ViewState. Man muss sich um alles selbst kümmern.

WebForms hingehen wurde auf Daten-lastige Anwendungen fokussiert / konzipiert und geht eher nach dem Prinzip des RapidDevelopments; es sollte vor allem aber auch den Einstieg der Windows Forms-Entwicklern erleichtern - daher auch diese Designentscheidung.

Übrigens lässt sich der ViewState auch serverseitig speichern. Hierzu kann ein individueller PagePersister verwendet werden, der die Daten serverseitig hält und nur eine eindeutige Kennung in der Seite ablegt.

Standardmäßig sollte ASP.NET einen SessionPagePersister zur Verfügung stellen. Der hält die Daten aber nur eine begrenzte Zeit vor. Im Web lassen sich durchaus Beispiele für einen SqlPagePersister finden, falls das eine Option wäre.