ASP.NET vraagje

[Verwijderd]

Is het mogelijk een C# class(gewoon standaard class) te "saven" zodat hij na een postback nog steeds aanwezig is ?! heb een pagina waar een class achterhangt die het eea aan informatie bewaard. Na een postback is die gewoon null en ik zou graag die class toch in het geheugen willen houden. of moet ik die bewaren in Sessions? iemand van jullie ?

[Verwijderd]

jep, bewaren in Session

[Verwijderd]

Niet bepaald 'chic'

[ Voor 34% gewijzigd door Verwijderd op 25-04-2003 11:50 ]

[Verwijderd]

hoe zou je het liever willen?

[Verwijderd]

Dat je in je class of in je codebehind kan aangeven dat de class onthouden moet worden tijdens een postback o.i.d.
Nu zul je dus als ik het goed begrijp bij elke knop of item die een postback veroorzaakt je class moeten saven naar je sessions.

[ Voor 38% gewijzigd door Verwijderd op 25-04-2003 12:08 ]

[Verwijderd]

Verwijderd schreef op 25 april 2003 @ 12:04:
Nu zul je dus als ik het goed begrijp bij elke knop of item die een postback veroorzaakt je class moeten saven naar je sessions.

Ik denk dat dat een beetje teveel van het goede is. Mijn inschatting is dat je alleen de class saved als er wijzigingen in zijn aangebracht o.i.d.
Dus, als je informatie uit je class opvraagt door een druk op een knop, en er treedt een postback op, dan hoef je niet je class te saven, omdat er niks aan is veranderd.

[Verwijderd]

Hmm, daar heb je wel gelijk in. Ik zal eens met die Session aan de gang gaan. Toch blijf ik het wel een beetje jammer vinden dat zoiets er niet in zit. Bedankt voor de hulp iig.

[mulder]

Kijk anders eens naar ViewState

[whoami]

Bewaren in de session of in de viewstate of ergens anders....

Zie ook hier:
[rml][ .NET] State in ASP.NET bewaren adhv Reflection en Attribute[/rml]

[Verwijderd]

Sorry hoor, ik ben nog een beetje een ASP.NET n00b, maar een ViewState, die word per pagina bijgehouden ?!. Hiervoor moet ik de class serializable maken. dit kan gewoon door [serializable] toe te voegen aan de class ?

[maikel]

Dat is niet altijd voldoende. Soms/vaak moet je ook nog twee methods maken (de namen weet ik zo even niet) die ervoor zorgen dat al je properties op de juiste manier worden opgeslagen en weer worden opgehaald.
In de help van VS.Net staan hiervan ook goede voorbeelden.

[Woy]

maikel schreef op 25 April 2003 @ 13:59:
Dat is niet altijd voldoende. Soms/vaak moet je ook nog twee methods maken (de namen weet ik zo even niet) die ervoor zorgen dat al je properties op de juiste manier worden opgeslagen en weer worden opgehaald.
In de help van VS.Net staan hiervan ook goede voorbeelden.

Volgens mij moet dit altijd goed gaan mits alle members van een class die het Serializable attribuut heeft ook Serializable zijn.

[maikel]

rwb schreef op 25 April 2003 @ 17:08:
[...]

Volgens mij moet dit altijd goed gaan mits alle members van een class die het Serializable attribuut heeft ook Serializable zijn.

Vandaar ook het "Soms/vaak".
Als je dus properties van een eigen type gebruikt, kun je tegen dit probleem aan lopen.
Of als je bijv. een DB-connectie ook wilt opslaan, dan moet je dus bijv. de connectionstring opslaan ipv de connectie zelf (kan namelijk niet).

[Verwijderd]

Ok. Wat is het voordeel van ViewState boven Sessie dan ? Allebij hebben ze dezelfde soort van aanroep namelijk :

C#:

ViewState["MyClass"] = myClass;
Session["MyClass"] = myClass;

[vinnux]

Viewstate wordt opgenomen in de pagina zelf en naar de client verstuurd.
MyClass wordt geserialized en opgenomen in een hidden field in het form, namelijk :

code:

<input type="hidden" name="__VIEWSTATE" value="dDwxOTQ0NDEyMjE3O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDU+O2k8MTI+
Oz47bDx0PHA8cDxsPE1heGltdW1WYWx1ZTtNaW5pbXVtVmFsdWU7VGV4dDs+O2w8
MTQtMy0yMDA0OzI3LTQtMjAwMztYOz4+Oz47Oz47dDxwPHA8bDxNYXhpbXVtVmFsd
WU7TWluaW11bVZhbHVlO1RleHQ7PjtsPDE0LTMtMjAwNDsyNy00LTIwMDM7WDs+Pjs
+Ozs+Oz4+Oz4+O2w8RGlyZWN0O05vblN0b3A7TWlycm9yO011bHRpQWlyOz4+CC0
4F/vxthXNXi4sSfrOhg93SKo=" />

Hoe groter de klasse is hoe groter dit stuk tekst wordt en daarmee de pagina.
Bij een postback wordt de klasse weer gedeserialized en hopla klasse terug. Erg arbeidintensief allemaal he

Wanneer MyClass in de Sessie gezet wordt, wordt deze niet naar de client gestuurd en wordt ie ook niet gesrialized en gedeserialized, maar staat ie gewoon inde de sessie table als referencie. Minder werkt en minmder foutgevoelig.

[ Voor 8% gewijzigd door vinnux op 26-04-2003 13:18 ]

[maikel]

vgouw schreef op 26 april 2003 @ 13:17:
Viewstate wordt opgenomen in de pagina zelf en naar de client verstuurd.
MyClass wordt geserialized en opgenomen in een hidden field in het form, namelijk :

code:

<input type="hidden" name="__VIEWSTATE" value="dDwxOTQ0NDEyMjE3O3Q8O2w8aTwwPjs+O2w8dDw7bDxpPDU+O2k8MTI+
Oz47bDx0PHA8cDxsPE1heGltdW1WYWx1ZTtNaW5pbXVtVmFsdWU7VGV4dDs+O2w8
MTQtMy0yMDA0OzI3LTQtMjAwMztYOz4+Oz47Oz47dDxwPHA8bDxNYXhpbXVtVmFsd
WU7TWluaW11bVZhbHVlO1RleHQ7PjtsPDE0LTMtMjAwNDsyNy00LTIwMDM7WDs+Pjs
+Ozs+Oz4+Oz4+O2w8RGlyZWN0O05vblN0b3A7TWlycm9yO011bHRpQWlyOz4+CC0
4F/vxthXNXi4sSfrOhg93SKo=" />

Hoe groter de klasse is hoe groter dit stuk tekst wordt en daarmee de pagina.
Bij een postback wordt de klasse weer gedeserialized en hopla klasse terug. Erg arbeidintensief allemaal he

Wanneer MyClass in de Sessie gezet wordt, wordt deze niet naar de client gestuurd en wordt ie ook niet gesrialized en gedeserialized, maar staat ie gewoon inde de sessie table als referencie. Minder werkt en minmder foutgevoelig.

Nadeel is dan alleen dat alles in de Sessie gooien niet echt een mooie oplossing is en dat dat nogal wat geheugen kan gaan kosten op de server als het een drukbezochte pagina is.
In de ViewState opslaan is een veel nettere oplossing.

[Verwijderd]

Hmm.. erg intressant wel deze discussie als zeg ik het zelf . Ik probeer een soort van MVC model aan te houden waarbij de interface(view) de aspx pagina is, de controller de code-behind, en het model de eigen gemaakte classes, als ik het bovenstaande lees is het opslaan in session mooier als ik kijk naar MVC, omdat viewstate word opgeslagen in de VIEW (aspx pagina) om het maar ff plat te beredeneren, en bij session op de server waardoor de scheiding tussen interface en model behouden blijft ?!

[vinnux]

Misschien leuk om te weten:
Codebehind is feitelijk geen code behind
Wanneer je een aspx pagina maakt met "Codebehind" erft die aspx pagina over van de "Codebehind" klasse. Dus feitelijk gezien is het niet eens Codebehind.

De aspx pagina wordt intern weer omgezet naar een normale klasse die overeft van de "Codebehind" klasse. Hiermee is het dus feitelijk gezien een klasse die je weer overal kunt gebruiken waar je maar wilt.

En of je wel of niet gegevens in de sessie moet bewaren hangt een beetje af van hoeveel het is en hoeveel geheugen je beschikbaar hebt. Trouwens kun je de sessie en andere gegevens ook weer opslaan op een aparte STATE server. .NET is zo schaalbaar als je het zelf wilt . Hiermee is het dus mogelijk om sessies over meerdere machines te gerbuiken.

[ Voor 23% gewijzigd door vinnux op 26-04-2003 22:40 ]

[Verwijderd]

Ik weet niet wat je wilt bewaren, maar het lijkt me wat betreft geheugen gebruik verstandig om een en ander in een database (sql of xml) te bewaren.

Bewaren mbv Viewstate: grotere files, dus pagina's langzamer, beveiligingsprobleem (viewstate is te decoderen)
Bewaren in Session: geheugen gebruik

[ Voor 20% gewijzigd door Verwijderd op 27-04-2003 17:34 ]

[Woy]

Om te kiezen waar je het opslaat ligt het er ook heel erg aan wat voor object het is. Als je bijvoorbeeld een counter object wil hebben van alle mensen die op je site komen dan zal je dit niet in je ViewState of Session opslaan maar in je Application. Dus het ligt er maar net aan in welke scope je je Object wil gebruiken

[dominic]

Heeft iemand al aan de cache gedacht? Nog simpeler.. Het grootste voordeel van cache t.ov. sessions is dat het volkomen veilig is (Dus niet over de lijn gepingpongd wordt)

Kijk eens naar de methods:

Cache.Add(naam, waarde, expiredate, slidingexpiretime, dependencies)
Cache.Get(naam)

Ik gebruik het zelf om sessiekeys op te slaan voor een ingelogde gebruiker.. werkt perfect.

[Woy]

dominic schreef op 28 april 2003 @ 09:37:
(Dus niet over de lijn gepingpongd wordt)

Ik weet niet precies wat jij hiermee bedoelt maar het Session object wordt echt niet telkens over de lijn gestuurd. Het enige wat meegestuurd word is een uniek SessionID. Zonder dit ID zou je nooit meer kunnen achterhalen welk Session object bij welke Client hoort.