[Løst] Problemer med Sesjoner i ASP.NET

[HDSoftware]

Folkens. Jeg prøver noe så enkelt som å få til sesjondata i ASP.NET

Jeg er en Win32 programmerer med relativt grei .NET kunnskap og skal altså prøve meg på ASP.NET og vil ha til følgende:

* Skjermbilde for kunder

* Skjermbilde for Ny/Endre kunde

* Skjermbilde for Login

 

>Burde være en grei sak.

Så har jeg lest meg til at en web side lever sitt eget liv, altså at manøvrering fra en side til en annen innebærer fullstendig ny oppstart av programmet. Greit nok. Men så leser jeg at det er noe som heter Session variabler og at jeg kan putte på sesjonen hva jeg vil før jeg redirecter, men jeg får det ikke til. Måten jeg har løst det på er som følger:

 

En GlobalData class som inneholder følgende:

Public class GlobalData

{

Public User CurrentUser;

Public Customer CurrentCustomer;

Public static GetGlobalData()

{

if (HttpContext.Current.Items.Contains("globalData") == false)

HttpContext.Current.Items.Add("globalData", New GlobalData());

Return (GlobalData)(HttpContext.Current.Items["globalData"]);

}

}

 

Så har jeg lagen en base class for alle WEB sidene mine, slik:

Public class WebPage : System.Web.UI.Page

{

Public GlobalData globalData = GlobalData.GetGlobalData();

Public WebPage()

{

if (this.GetType().ToString().ToUpper() != "ASP.WLOGIN_ASPX")

if (globalData.CurrentUser == null)

Server.Transfer("/wLogin.aspx", true);

}

}

Som dere ser her så prøver jeg altså å danne en instans av GlobalData som skal leve på tvers av alle WebForms, men det funker ikke. Hver gang jeg utfører en Server.Transfer("asp.net side") så mister jeg dataene og Login bildet dukker opp igjen. Det vil si, når jeg har logget inn så kommer jeg til siden jeg skal.

Når jeg kjører i Debug mode og setter breakpoint her og der så ser jeg jo at instansen av GlobalData ikke eksisterer.

 

Dette er sikker en enkel sak å få til, men jeg ser det ikke. Fint om dere kan hjelpe meg litt i gang her.

Endret 3. november 2014 av HDSoftware

[ahw_]

Så har jeg lest meg til at en web side lever sitt eget liv, altså at manøvrering fra en side til en annen innebærer fullstendig ny oppstart av programmet.

Korriger meg hvis jeg tar feil, men jeg mener hele app'en starter opp fra grunnen første gangen og hver gang det kjøres en «recycle» (kan skje når som helst). Hver forespørsel fra klienten lager dog en helt ny instans av din Controller (MVC) eller hva enn det kalles når man ikke bruker MVC.

Først, ta en titt her ang. HttpContext.Items:

http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items%28v=vs.110%29.aspx

Det står faktisk ingenting om sessions der, så det er nok ikke helt det du vil ha. I stedet er det HttpContext.Session du vil bruke:

http://msdn.microsoft.com/en-us/library/system.web.httpcontext.session%28v=vs.110%29.aspx

 

Endret 3. november 2014 av ahw_

[HDSoftware]

Dette var nok enklere enn som så. AHW_ er inne på saken, men ikke helt. Problemet var rett og slett at Session er en property på WEB page class og kan derfor ikek uten videre brukes i en annen klasse. Flyttet derfor for det første dette til WebPage klassen samtidig som jeg byttet ut HttpContext.Current.Items.o.s.v. med noe så enkelt som Session["VariabelName"] og dermed funket alt sammen.

 

Var det jeg visste jeg, dette var enkle greier ;-)

[GeirGrusom]

Dette var nok enklere enn som så. AHW_ er inne på saken, men ikke helt. Problemet var rett og slett at Session er en property på WEB page class og kan derfor ikek uten videre brukes i en annen klasse. Flyttet derfor for det første dette til WebPage klassen samtidig som jeg byttet ut HttpContext.Current.Items.o.s.v. med noe så enkelt som Session["VariabelName"] og dermed funket alt sammen.

 

Var det jeg visste jeg, dette var enkle greier ;-)

ahw_ har helt rett. HttpContext.Current.Items lever bare igjennom requesten.

 

edit: vil legge til at du kanskje burde vurdere dependency injection.

Endret 12. november 2014 av GeirGrusom

[HDSoftware]

 

Dette var nok enklere enn som så. AHW_ er inne på saken, men ikke helt. Problemet var rett og slett at Session er en property på WEB page class og kan derfor ikek uten videre brukes i en annen klasse. Flyttet derfor for det første dette til WebPage klassen samtidig som jeg byttet ut HttpContext.Current.Items.o.s.v. med noe så enkelt som Session["VariabelName"] og dermed funket alt sammen.

 

Var det jeg visste jeg, dette var enkle greier ;-)

ahw_ har helt rett. HttpContext.Current.Items lever bare igjennom requesten.

 

edit: vil legge til at du kanskje burde vurdere dependency injection.

 

Hva tenker du på når du sier DI ? Bruker dette støtt og stadig i WinForms, men ser ikke helt hvordan jeg skal få dette til i WebForms siden alle sidene strengt tatt er nye instanser. Var inne på å lage en "global event handler" men slo det fra meg fordi jeg ikek fant ut hvordan jeg kunne erstatte clientside uten å bruke en eller annen form form Transfer. Er derfor jeg går veien om en Session variabel, men hvis du vet om noe lurere så kom igjen. You got my attention...

[MailMan13]

Edit: nvm. besvart over

Endret 12. november 2014 av MailMan13

[GeirGrusom]

Hva tenker du på når du sier DI ? Bruker dette støtt og stadig i WinForms, men ser ikke helt hvordan jeg skal få dette til i WebForms siden alle sidene strengt tatt er nye instanser. Var inne på å lage en "global event handler" men slo det fra meg fordi jeg ikek fant ut hvordan jeg kunne erstatte clientside uten å bruke en eller annen form form Transfer. Er derfor jeg går veien om en Session variabel, men hvis du vet om noe lurere så kom igjen. You got my attention...

Nå bruker ikke jeg WebPages, men det er rimelig vanlig å ha et IoC rammeverk som injiserer ting i constructoren (slik som GlobalData i ditt tilfelle) ettersom det fjerner en del kodeduplisering, og kan bedre legge til rette for unit-testing.

[HDSoftware]

 

Hva tenker du på når du sier DI ? Bruker dette støtt og stadig i WinForms, men ser ikke helt hvordan jeg skal få dette til i WebForms siden alle sidene strengt tatt er nye instanser. Var inne på å lage en "global event handler" men slo det fra meg fordi jeg ikek fant ut hvordan jeg kunne erstatte clientside uten å bruke en eller annen form form Transfer. Er derfor jeg går veien om en Session variabel, men hvis du vet om noe lurere så kom igjen. You got my attention...

Nå bruker ikke jeg WebPages, men det er rimelig vanlig å ha et IoC rammeverk som injiserer ting i constructoren (slik som GlobalData i ditt tilfelle) ettersom det fjerner en del kodeduplisering, og kan bedre legge til rette for unit-testing.

 

Ja, men finner ingen måte å bruke denne konstruktøren på. Du kan så vidt jeg vet ikke kalle konstruktøren fordi du uansett må sende en REDIRECT til klienten og resultatet er at objektet blir konstruert på nytt med default constructor og dermed har du mistet det du injiserte.

[MailMan13]

 

Nå bruker ikke jeg WebPages, men det er rimelig vanlig å ha et IoC rammeverk som injiserer ting i constructoren (slik som GlobalData i ditt tilfelle) ettersom det fjerner en del kodeduplisering, og kan bedre legge til rette for unit-testing.

 

 

Constructor injection går ikke med WebForms ut av boksen. Endelige klasser for aspx og ascx-filer med tilhørende kode (codebehind) blir generert runtime med constructor som man ikke har tilgang på. Koden man skriver selv er bare baseklassen til den endelige klassen.

 

Om man absolutt vil, kan man implementere en egen PageHandlerFactory med tilhørende reflection-magi.

Endret 13. november 2014 av MailMan13

[GeirGrusom]

Constructor injection går ikke med WebForms ut av boksen. Endelige klasser for aspx og ascx-filer med tilhørende kode (codebehind) blir generert runtime med constructor som man ikke har tilgang på. Koden man skriver selv er bare baseklassen til den endelige klassen.

 

Om man absolutt vil, kan man implementere en egen PageHandlerFactory med tilhørende reflection-magi.

Idiotisk.

[HDSoftware]

 

Constructor injection går ikke med WebForms ut av boksen. Endelige klasser for aspx og ascx-filer med tilhørende kode (codebehind) blir generert runtime med constructor som man ikke har tilgang på. Koden man skriver selv er bare baseklassen til den endelige klassen.

 

Om man absolutt vil, kan man implementere en egen PageHandlerFactory med tilhørende reflection-magi.

Idiotisk.

 

Tja, egentlig ikke. Det er jo sånn at en web side er en forespørsel fra nettleseren og det er umulig for serveren å vite hva du har drivi med. Derfor lages det en session og ID til denne blir vel lagret HTML dokumentet som kommer over slik at nettleseren kan sende denne tilbake når du gjør valg i web siden. Dermed kan serveren plukke frem alle sesjonsvariabler. Fungerer egentlig ganske greit. Det er rett og slett en collection av OBJECT så det er jo bare å caste i koden og alt er på plass, innenfor timeout så klart for alle sesjonsvariabler blir disposet etter timeout

[GeirGrusom]

Tja, egentlig ikke. Det er jo sånn at en web side er en forespørsel fra nettleseren og det er umulig for serveren å vite hva du har drivi med. Derfor lages det en session og ID til denne blir vel lagret HTML dokumentet som kommer over slik at nettleseren kan sende denne tilbake når du gjør valg i web siden. Dermed kan serveren plukke frem alle sesjonsvariabler. Fungerer egentlig ganske greit. Det er rett og slett en collection av OBJECT så det er jo bare å caste i koden og alt er på plass, innenfor timeout så klart for alle sesjonsvariabler blir disposet etter timeout

Akkurat det samme skjer i MVC også men der er det fullstendig trivielt å bruke DI. En controller blir opprettet per request, og referanser blir injectet i controlleren. Controlleren bruker referansen til å bygge opp response. Web Forms gjør akkurat det samme, men har ikke noen måte å legge inn DI på.

[MailMan13]

Tja, egentlig ikke. Det er jo sånn at en web side er en forespørsel fra nettleseren og det er umulig for serveren å vite hva du har drivi med. Derfor lages det en session og ID til denne blir vel lagret HTML dokumentet som kommer over slik at nettleseren kan sende denne tilbake når du gjør valg i web siden. Dermed kan serveren plukke frem alle sesjonsvariabler. Fungerer egentlig ganske greit. Det er rett og slett en collection av OBJECT så det er jo bare å caste i koden og alt er på plass, innenfor timeout så klart for alle sesjonsvariabler blir disposet etter timeout

 

 

Ingenting av det du lister opp trenger å være et problem. ASP.NET MVC (og en røys av andre web-rammeverk) viser hvordan det kan gjøres.

 

Problemene oppstår når rammeverket tvinger deg til å skrive kode som implisitt er hardkodet sammen med statiske properties i HttpContext. Da ender man opp med kode som ikke kan brukes utenfor et fullt web-runtime.

 

Nå tilbyr forsåvidt WebForms at man kan lage en egen PageHandlerFactory som løser DI i seg selv, men den er langt fra enkel å ta i bruk. (og løser jo ikke problemet med dependencies på HttpContext.)

Endret 14. november 2014 av MailMan13

[HDSoftware]

 

Tja, egentlig ikke. Det er jo sånn at en web side er en forespørsel fra nettleseren og det er umulig for serveren å vite hva du har drivi med. Derfor lages det en session og ID til denne blir vel lagret HTML dokumentet som kommer over slik at nettleseren kan sende denne tilbake når du gjør valg i web siden. Dermed kan serveren plukke frem alle sesjonsvariabler. Fungerer egentlig ganske greit. Det er rett og slett en collection av OBJECT så det er jo bare å caste i koden og alt er på plass, innenfor timeout så klart for alle sesjonsvariabler blir disposet etter timeout

 

 

Ingenting av det du lister opp trenger å være et problem. ASP.NET MVC (og en røys av andre web-rammeverk) viser hvordan det kan gjøres.

 

Problemene oppstår når rammeverket tvinger deg til å skrive kode som implisitt er hardkodet sammen med statiske properties i HttpContext. Da ender man opp med kode som ikke kan brukes utenfor et fullt web-runtime.

 

Nå tilbyr forsåvidt WebForms at man kan lage en egen PageHandlerFactory som løser DI i seg selv, men den er langt fra enkel å ta i bruk. (og løser jo ikke problemet med uløselige dependencies på HttpContext.)

 

haha, så klart. Og EntityFramework gjør at jeg ikke trenger å skrive SQL uttrykk i strenger for å få data. Men dette forutsetter kunnskap på feltet. Jeg er ny på web programmering og gikk for standard asp.net i dette mikro prosjektet. Skulle gjerne brukt MVC jeg, men har null erfaring med det.

 

På den annen side så fikk dere meg interessert. Hva bør jeg studere for å komme kjapt igang med dette?

[GeirGrusom]

haha, så klart. Og EntityFramework gjør at jeg ikke trenger å skrive SQL uttrykk i strenger for å få data. Men dette forutsetter kunnskap på feltet. Jeg er ny på web programmering og gikk for standard asp.net i dette mikro prosjektet. Skulle gjerne brukt MVC jeg, men har null erfaring med det.

 

På den annen side så fikk dere meg interessert. Hva bør jeg studere for å komme kjapt igang med dette?

MVC er litt mindre intuitivt enn Web Forms, men det er langt mer konsekvent. Det er sjeldent overraskelser i hvordan det oppfører seg.

 

Eneste jeg egentlig har vært borti av gotchas i MVC er at DateTime serialiseres forskjellig mellom GET og POST. GET bruker CurrentCulture, mens POST bruker InvariantCulture. Hadde en bug på dette etter jeg byttet en sak fra å bruke POST til å bruke GET (som den burde gjort fra starten av).