[ASP.NET] ViewState: alles of niets

[Verwijderd]

Wat ik een beetje jammer vind, is dat het gebruik van de ViewState een alles-of-niets scenario is. Als je bijvoorbeeld in een DataGrid gebruik wilt maken van Paging (zonder db-roundtrips), zou je eigenlijk gebruik willen maken van de ViewState.
Het nadeel is echter dat je data dan 2x in je pagina wordt ingeladen (1x in de ViewState en 1x in het control zelf). Als je het DataGrid voor inline editing gebruikt, is dat misschien wel iets wat je wilt, maar als je het DataGrid slechts gebruikt om wat records te tonen, zou je eigenlijk makkelijk zonder die ViewState kunnen...

Wat ik in een andere thread al als conclusie gaf was:
- Als je per pagina weinig data ophaalt -> ViewState gebruiken (want scheelt je een roundtrip naar de database)
- Als je per pagina soms en veel data ophaalt -> Geen ViewState gebruiken (want pagina wordt anders tenminste 2x zo groot), maar gewoon steeds opnieuw een BindData().

Maar hoe los je "het probleem" van Paging op het DataGrid dan op, zonder db-roundtrip? En wat doe je als je vaak en veel data ophaalt (want dan wil je ook liever zo weinig mogelijk db-roundtrips)?

Wat zijn jullie ervaringen van de ViewState en ervaar je het ook als een probleem dat het 'alles-of-niets' is? (alles: voordelen van de ViewState, maar 2x zo grote pagina, wat soms wel kan leiden tot pagina's van 1MB; niets: geen ViewState)

Related topics
ASP.NET DataSet opslaan als Session?
[rml][ ASP.NET] Event voor OnLoad?[/rml]

[Nielsz]

viewstate
Een simpel tabelletje van 14 records wordt hier al 44 kb. Grotere pagina's worden al snel 200 kb. Erg fijn met je 56.6
Viewstate is echt het slechtste wat ze hebben kunnen verzinnen sinds, sinds, naja sinds iets.
Liever 0,1 seconde bezig zijn met data opnieuw ophalen, dan om 3 minuten op m'n pagina te wachten.

[sander_g]

Viewstate werkt prima als je het gebruikt waar het voor bedoeld is.

Dat wil zeggen: als je kleine hoeveelheden data in een pagina wilt bewaren voor postbacks naar de zelfde pagina kan je ViewState gebruiken.

Als je geen roundtrips wil maar je wilt de data wel clientside laten bewerken, dan ontkom je er toch niet aan om op de 1 of andere manier die data naar de client te halen?

Voor grote datasets moet je volgens mij server-side statemanagement gebruiken.

[Verwijderd]

Nielsz schreef op 04 november 2002 @ 12:06:
Liever 0,1 seconde bezig zijn met data opnieuw ophalen, dan om 3 minuten op m'n pagina te wachten.

Ja, vooral als je iets van 1000 concurrent users op je systeem hebt zitten... Dan heeft je db-server tenminste ook iets te doen.

---
Cache misbruiken kan een optie zijn als je data niet zo vaak verandert, maar de Session is volgens mij echt een 'NoGo': Als je dan bijvoorbeeld een nieuw window opent en je gaat daar nieuwe data mee inladen, krijgt je oude window stiekum ook die nieuwe data via de Session mee... Dan kun je hele vreemde situaties krijgen.

Ik ben 't er mee eens dat de ViewState soms echt is, maar echt een andere (goeie) oplossing heb ik ook nog niet gevonden.

[Nielsz]

Verwijderd schreef op 04 november 2002 @ 13:58:
[...]

Ja, vooral als je iets van 1000 concurrent users op je systeem hebt zitten... Dan heeft je db-server tenminste ook iets te doen.

---
Cache misbruiken kan een optie zijn als je data niet zo vaak verandert, maar de Session is volgens mij echt een 'NoGo': Als je dan bijvoorbeeld een nieuw window opent en je gaat daar nieuwe data mee inladen, krijgt je oude window stiekum ook die nieuwe data via de Session mee... Dan kun je hele vreemde situaties krijgen.

Ik ben 't er mee eens dat de ViewState soms echt is, maar echt een andere (goeie) oplossing heb ik ook nog niet gevonden.

Duizend mensen 3 minuten laten wachten, van het geld wat dat kost kan je allang een nieuwe dbserver kopen
En sommige tabellen kan je gewoon cachen (owh, dat zei je zelf ook al ). Als ik een pagina opvraag, dan moet ik er vanuit kunnen gaan dat die data het allernieuwste is. Zeker met 1000 concurrent users is de kans 'aanwezig' dat iemand al die data veranderd heeft.

[Verwijderd]

Ok, misschien moet ik "het probleem" iets beter schetsen.
- We hebben veel concurrent users (die de data niet mogen veranderen);
- We hebben veel data in een DataGrid;
- Het is zoveel data dat we gebruik willen maken van Paging.

Als je gebruik wilt maken van de Paging-mogelijkheden van het DataGrid moet je de ViewState gebruiken. Nadeel: Grote pagina.
Als je steeds "nieuwe" data (nieuw is hier dan dus de data van een andere page) wilt ophalen uit de database om zo paging mogelijk te maken, heb je als nadeel dat je veel db-roundtrips hebt, wat met veel concurrent users ook niet echt prettig is.
Uiteraard kun je al die data ook wel cachen op de webserver, om zo je database-server iets te ontlasten, maar dan nog is dit volgens mij niet zo'n fijne oplossing, omdat je dan nog steeds met server-roundtrips zit en als je dus maar een 56k6 modempje hebt, vind je dat ook niet leuk. En dan is de 1e situatie misschien weer aantrekkelijker: 1x lang wachten, maar als je eenmaal alles binnenhebt, kun je lekker doorklikken.

Naar mijn idee heb je dus in deze specifieke situatie een keus uit 3 slechte mogelijkheden...

[mulder]

Verwijderd schreef op 04 november 2002 @ 14:19:

Uiteraard kun je al die data ook wel cachen op de webserver, om zo je database-server iets te ontlasten, maar dan nog is dit volgens mij niet zo'n fijne oplossing, omdat je dan nog steeds met server-roundtrips zit en als je dus maar een 56k6 modempje hebt, vind je dat ook niet leuk. En dan is de 1e situatie misschien weer aantrekkelijker: 1x lang wachten, maar als je eenmaal alles binnenhebt, kun je lekker doorklikken.

Volgens mij stuurt de server nog altijd een html pagina terug met 1 Page van het grid. Dus zal de pagina zelf niet echt zwaar zijn. Maar doe anders een paar testjes, dan heb je misschien een beter beeld over de serverbelasting. Persoonlijk denk ik niet dat de viewstate bedoeld is om veel data in op te slaan.

[Nielsz]

Ik zie even niet in wat er mis is met het cachingmechanisme. Viewstate is alleen maar handig als je data veranderd. Aangezien dat niet het geval is, hoef je het ook niet mee te sturen. Daarom moet je de data 'ophalen' vanaf de webserver. De keuze tussen cache(webserver) of db (dbserver) is dan toch snel gemaakt aangezien het allemaal readonly is?

[Verwijderd]

Nielsz schreef op 04 november 2002 @ 14:43:
Ik zie even niet in wat er mis is met het cachingmechanisme. [...] Daarom moet je de data 'ophalen' vanaf de webserver.

Dat laatste is wat ik tegen caching hebt: je hebt dan toch nog steeds een roundtrip naar de (web)server? Het mooie van de ViewState was nu juist dat de gebruiker die roundtrip bespaard blijft.

[Nielsz]

Hoe bedoel je? Je moet toch nog steeds naar de server om aan te geven welke pagina er opgebouwd moet worden? Alleen haal je niet de data uit de cache of database, maar uit een POSTvariabele.
Of zie ik het nu helemaal verkeerd?

[mulder]

Verwijderd schreef op 04 november 2002 @ 14:52:
[...]

Dat laatste is wat ik tegen caching hebt: je hebt dan toch nog steeds een roundtrip naar de (web)server? Het mooie van de ViewState was nu juist dat de gebruiker die roundtrip bespaard blijft.

Euuuh... denk je dan dat dat grid clientside browsing code gebruikt?