Objekter og WEB Sider

[HDSoftware]

Heisan folkens.

 

Jobber med en WEb app og lurer på om objekter kan "passes" over til nye sider.

 

Sett at man har følgende klasse i App_Code

public class Sikkerhet
{
 private string Brukernavn;
 private string PassHash;
 private int _AccessLevel;

 private MyDBDataContext db = new MyDBDataContext();

 publuc int _AccessLevel
 {
get{ return _AccessLevel; }
 }

 public bool Login(string pUserName, string pPassword)
 {
Brukernavn = pUserName;
PassHash = pPassword.GetHashCode()
_AccessLevel = db.GetUserAccessLevel(pUserName, pPassword.GetHashCode());
					//db.GetUserAccessLevel er en storedprocedure på SQL serveren
if (AccessLevel <> 0)
  return true;
else
  return false;
 }
}

Dette instanseres som et objekt på default.aspx. Men når jeg kaller en annen side så ønsker jeg jo at objektet fortsatt skal brukes på de andre sidene. Til å begynne med så lagret jeg brukernavn og passhash i session variabler, men har en pussig magefølelse av at dette ikek er en trygg måte å gjøre det på, men at et instansert objekt likegodt kan håndtere dette. Finner bare ikek helt hvordan jeg skal sende en referanse fra en side til en annen. Leste et sted at web sider må ses på som frittstående applikasjoner, men det må da være mulig å gjøre dette så lenge man opererer med codebehind og objekter - eller går det bare ikke?

 

Ole

[j000rn]

Session er trygt ja.

 

Du kan lage static variabler i ASP.Net også, men husk at "applikasjonen" din vil være delt mellom alle brukerene, så i dette tilfellet vil det ikke være hensiktsmessig.

 

 

Et lite tips; ALDRI bruk "Session" i koden din.

Dvs; Koden din == på enkelt sider.

 

Lag heller en "wrapper" klasse, f.eks. Sikkerhet;

 

internal class Security
{
 private Security() // Så kan ikke klasse opprettes andre steder
 {
 }

 // TODO : Add errorchecking/etc...
 internal static int UserID
 {
get
{
	return HttpContext.Current.Session["UserID"];
}
set
{
	HttpContext.Current.Session["UserID"] = value;
}
 }

 internal static int Email
 {
get
{
	return HttpContext.Current.Session["Email"];
}
set
{
	HttpContext.Current.Session["Email"] = value;
}
 }
}

 

Dermed kan du bruke Security.UserID / Security.Email overalt i koden din. Dermed unngår du at du skriver Session["SkriveFeilInniHer"] i koden din. Denne typen feil er ofte veldig vanskelige å finne ut av å debugge. Dessuten blir session variablene dine type-safe, og du får mindre kode...

 

 

btw; Det kan være en god vane å bruke public/internal/private ordentlig fra begynelsen av. Det gjør det utrolig mye enklere når du evt. skal Obfuscate prosjektet ditt senere.

[HDSoftware]

Takker. Dette gjør selvsagt Sessionmere brukervennlig. Men siden du ikke sier noe om det temaet jeg egentlig spurte etter: Betyr det at et objekt umulig kan leve mellom to web sider? Og at jeg derfor må reinstansere alle objektene mine for hver side? Virker jo litt ungvint da, men ok.

 

Når det gjelder public/private etc. så bruker jeg alltid det. Ser i eksemplet mitt at jeg ikek hadde noe foran selve klassen. Var bare jeg som glemte å skrive det i eksemplet. Koden over er ikek hentet fra noen app hos meg. Ville bare visualisere hva jeg ville ha til, men takker for tipset.

[j000rn]

For hver eneste postback kan du se det som om applikasjonen starter på nytt. Derfor må alle objekter instanseres på nytt og verdier settes inn. Mye av dette gjør ASP.Net for deg automatisk, men uansett kan det være greit å tenke seg at du lager et Windowsprogram og for hver knapp du trykker på eller dropdownboks du endrer så avsluttes programmet og starter på nytt - og alt må lastes inn igjen... Nesten slik fungerer ASP.Net under panseret.

 

Du kan sende verdier/"objekter" mellom 2 postbacks/sider. Her har du 3 måter å gjøre dette på; Form post, querystring og cookies (+ andre som ikke blir brukt så ofte - headere, andre post typer, etc).

 

Ikke så mange valgmuligheter som du ser Session er egentlig bare en cookie som refererer til en viss sted i minnet(/fil/sql server,etc).

 

Med de 3 måtene kan du serialisere objekter og sende dem mellom sidene. ViewState/ControlState gjør dette automatisk for deg innenfor 1 side.

[j000rn]

Betyr det at et objekt umulig kan leve mellom to web sider?

 

Objektene dine kan leve i f.eks. Session , Application (obsolete - bruk static), static, cache, filer, databaser, på andre maskiner, på browseren, etc. Men de kan ikke leve "mellom to web sider" nei...

 

ViewState kan brukes for å lagre objektet, sende det til browseren, som sender det tilbake, og lastes av ASP.Net igjen. Men det fungerer kun ved postback på samme side.

[HDSoftware]

Skjønner. Var vel dette jeg kom frem til i en artikkel jeg leste også. Men du nevner Serialize. Betyr det at jeg kan bruke Serialize på et objekt inn i en Session variabel go så "caste" den inn i et nytt object i en ny web side?. F.eks. noe slik:

 

MyClass MyObject = new MyClass()
MyObject.Property1 = 123
MyObject.Property2 = "Hello World"
Session["Objektet"] = MyObject;

 

Og så i neste web side

MyClass MyOtherObject = new MyClass()
MyOtherObject = (MyClass)Session["Objektet"];

 

Ser jo på MSDN at jeg kan gjøre dette med en ArrayList. Hmmm. Åpner virkelig for muligheter hvis dette går. Hvis dette går, er det så en begrensning for hva som kan "pøses" over i en session variabel?

 

Ole

[HDSoftware]

Skjønner. Var vel dette jeg kom frem til i en artikkel jeg leste også. Men du nevner Serialize. Betyr det at jeg kan bruke Serialize på et objekt inn i en Session variabel go så "caste" den inn i et nytt object i en ny web side?. F.eks. noe slik:

 

MyClass MyObject = new MyClass()
MyObject.Property1 = 123
MyObject.Property2 = "Hello World"
Session["Objektet"] = MyObject;

 

Og så i neste web side

MyClass MyOtherObject = new MyClass()
MyOtherObject = (MyClass)Session["Objektet"];

 

Ser jo på MSDN at jeg kan gjøre dette med en ArrayList. Hmmm. Åpner virkelig for muligheter hvis dette går. Hvis dette går, er det så en begrensning for hva som kan "pøses" over i en session variabel?

 

Ole

 

Jippie!! Det virker som bare det ;-) Den tar til og med private properties ;-)

[j000rn]

Som default ligger Session i RAM i IIS, slik at det ikke trenger å bli serialisert.

ViewState blir automatisk serialisert for deg.

Om du skal legge objekter i cookies, hidden felter, sende over nettverket, lagre i fil eller database, etc så kan du serialisere dem (til XML eller binær).

 

Alt kan puttes i Session ja. Greit å unngå å putte kontroller der, objekter som har åpne ressurser (database, fil, nettverk, etc --- egentlig alt som implementerer IDisposable), eller data som tar veldig mye minne.

Endret 16. juli 2008 av jorn79

[HDSoftware]

Som default ligger Session i RAM i IIS, slik at det ikke trenger å bli serialisert.

ViewState blir automatisk serialisert for deg.

Om du skal legge objekter i cookies, hidden felter, sende over nettverket, lagre i fil eller database, etc så kan du serialisere dem (til XML eller binær).

 

Alt kan puttes i Session ja. Greit å unngå å putte kontroller der, objekter som har åpne ressurser (database, fil, nettverk, etc --- egentlig alt som implementerer IDisposable), eller data som tar veldig mye minne.

ok. Skal unngå dette. Men dette med sesjoner åpner virkelig en masse dører for meg. Du nevnte at jeg kunne lage STATIC variabler og at dette ville bli delt med hele applikasjonen på tvers av brukere? Betyr dette at jeg f.eks. kan lage en statisk LIST<> som inneholder eksempelvis påloggede brukere som vil kunen ses av alle som ser på siden?

 

Påkker! Dette er tøfft! Skulle begynnt med WEB programmering for lenge siden skjønner jeg

[j000rn]

Du nevnte at jeg kunne lage STATIC variabler og at dette ville bli delt med hele applikasjonen på tvers av brukere? Betyr dette at jeg f.eks. kan lage en statisk LIST<> som inneholder eksempelvis påloggede brukere som vil kunen ses av alle som ser på siden?

 

Jepp. Men litt avhengig av hva du skal bruke det til ville jeg heller vurdert å bruke en database. Husk at IIS kan finne på å "resirkulere" web'n din, den kan kræsje, etc. I tillegg er static per. maskin, så om du skal bruke load-balancing senere kan det være et problem.

[HDSoftware]

Du nevnte at jeg kunne lage STATIC variabler og at dette ville bli delt med hele applikasjonen på tvers av brukere? Betyr dette at jeg f.eks. kan lage en statisk LIST<> som inneholder eksempelvis påloggede brukere som vil kunen ses av alle som ser på siden?

 

Jepp. Men litt avhengig av hva du skal bruke det til ville jeg heller vurdert å bruke en database. Husk at IIS kan finne på å "resirkulere" web'n din, den kan kræsje, etc. I tillegg er static per. maskin, så om du skal bruke load-balancing senere kan det være et problem.

Bruker selvsagt database. Men ser problemstillingen rundt Load Balance. Hadde vel trodd at IIS i cluster ville fikse dette av seg selv, men det spiller egentlig liten rolle. Var bare ute etter om teknikken kunne brukes på den måten og det kan det jo.

[j000rn]

Jeg sa som default så kjører Session på IIS. Du kan også sette opp en separat IIS server som alle de andre bruker for å lagre sessions, eller du kan bruke SQL Server som session state server.... Du kan tilogmed lage din egen Session state provider hvor du selv velger hvordan objektene skal lagres

 

Poenget er at man har mange valg, og det kanskje lønner seg å tenke litt igjennom fordeler og ulemper før man setter igang

 

Uansett så lenge du har abstrakther "Session" koden ut i 1 fil som i første eksemplet mitt så blir det jo enklere å evt. forandre i fremtiden.... + de andre fordelene jeg nevnte.

[HDSoftware]

Jeg sa som default så kjører Session på IIS. Du kan også sette opp en separat IIS server som alle de andre bruker for å lagre sessions, eller du kan bruke SQL Server som session state server.... Du kan tilogmed lage din egen Session state provider hvor du selv velger hvordan objektene skal lagres

 

Poenget er at man har mange valg, og det kanskje lønner seg å tenke litt igjennom fordeler og ulemper før man setter igang

 

Uansett så lenge du har abstrakther "Session" koden ut i 1 fil som i første eksemplet mitt så blir det jo enklere å evt. forandre i fremtiden.... + de andre fordelene jeg nevnte.

Vet ikek om jeg forstår deg rett nå, men mener du at jeg kan selv bestemme hvor session variablene skal ligge? F.eks. i en SQL tabell eller XML fil?

[j000rn]

Providere som er støttet allerede:

* Inproc (IIS ram) - default - Raskeste, skalerer ikke, forsvinner ofte på grunn av restart av IIS worker process. Bør ikke vare for lenge (default 20 min) på grunn av at det bruker minne.

* State Server (iIS ram på en annen maskin) - Treigere, skalerer litt, forsvinner kun hvis serveren restarter.

* SQL Server - Treigest, skalerer bra. Kan sette til å vare "uendelig" om du ønsker.

 

I tillegg kan du programmere dine egne. F.eks. XML filer ja, selv om det hørtes utrolig lite effektivt ut...

[alftore]

Så lenge det er brukerdata er det fint å bruke Sessions ellers ville jeg sett på Cache

 

 

XML filer høres ut som en glimrende løsning ja

Endret 16. juli 2008 av alftore

[Manfred]

bare fordi jeg hadde lyst til å pirke. Du skrev denne koden:

 

MyOtherObject = (MyClass)Session["Objektet"];

 

Så kunne du heller brukt as, som er en safe cast:

 

MyOtherObject = Session["Objektet"] as MyClass;

 

Den øverste vil kaste en exception dersom casten ikke kan gjennomføres, mens den andre vil bare sette den til null.

[HDSoftware]

bare fordi jeg hadde lyst til å pirke. Du skrev denne koden:

 

MyOtherObject = (MyClass)Session["Objektet"];

 

Så kunne du heller brukt as, som er en safe cast:

 

MyOtherObject = Session["Objektet"] as MyClass;

 

Den øverste vil kaste en exception dersom casten ikke kan gjennomføres, mens den andre vil bare sette den til null.

Godt poeng

[HDSoftware]

En ting til:

Må jeg NEW'e objektet hvis jeg tilorner på denne måten?

altså:

MyClass MittObject = new MyClass();
MittObject = Session["Objektet"] as MyClass;

Er dette strengt tatt nødvendig, eller holder dette?

MyClass MittObject = Session["Objektet"] as MyClass;

[j000rn]

MyClass MittObject = new MyClass();
MittObject = Session["Objektet"] as MyClass;

 

Først lager du et nytt objekt. Og så overskriver du dette med det du har i Session.

Hørtes det lurt ut? :!:

[Manfred]

MyClass MyObject = (Session["Object"] as MyClass) ?? new MyClass();