Et innblikk i statens ledelsesteknikker som tilbys av ASP.NET

Det er en felles begrensning som kan observeres i funksjonen til nesten alle nettapplikasjoner, noe som øker deres statsløse oppførsel. Det er den intermitterende forbindelsen mellom serveren og klienten.

Det som skjer er at mens du implementerer HTTP (Hyper Text Transfer Protocol) for kommunikasjon over nettet, følges et bestemt mønster som er kjent som forespørsel og respons. Dette mønsteret er faktisk statsløst ettersom det ikke beholder tilstanden til noen forespørsel eller dets tilsvarende svar. Derfor når en klient starter en forespørsel til webserveren, oppretter webserveren et helt nytt objekt for forespørselen. Dette forårsaker til slutt avbrudd i forbindelsen og skaper flaskehalser i ytelsen.

Heldigvis tilbyr ASP.NET en flott løsning for å overvinne dette problemet med flere effektive tilstandsstyringsteknikker for webapplikasjoner.

La oss tenke på de fantastiske tilbudene til ASP.NET og forstå hvordan det hjelper til med å beholde statusen til kontrollene.

Det har blitt observert at når forespørsels- og svarmønsteret skaper rundturene, blir serverkontrollverdien på en eller annen måte solgt mens HTML-kontrollverdien forsvinner. Dette er fordi Sever Controls implisitt implementerer State Management-teknikken (View State), som har gjort det mulig for den å beholde tilstandene.

ASP.NET tilbyr en rekke strålende tilstandsstyringsmetoder, alle er ment for forskjellige applikasjoner. De er i utgangspunktet atskilt under to brede kategorier, nemlig klientbasert tilstandsadministrasjon og serverbasert tilstandsstyring. Her er en kort introduksjon til flere teknikker.

Klientbasert statsforvaltning

I denne tilnærmingen lagres dataene på klientens maskin eller på siden uten å involvere serverens ressurser. Disse lagrede dataene inkluderer all informasjon relatert til interaksjonen mellom klienten og serveren. Siden dataene er lagret ved klientens ende, er de mer sårbare for å bli hacket, noe som gjør teknikkene mindre sikre samtidig som de er mer skalerbare.

Med denne tilnærmingen letter ASP.NET metodene nedenfor:

1) Vis tilstand:

Denne metoden på sidenivå hjelper til med å lagre informasjonen om en bestemt side til den er aktiv. Det vil si at så snart brukeren omdirigerer til en annen side, vil all lagret informasjon forsvinne. Det bidrar dermed til å opprettholde tilstanden på sidenivå. I denne teknikken lagres dataene i skjemaet Dictionary Object (i paret av nøkkel og verdi). All informasjon lagres i et hashed-format på selve siden, men innenfor et skjult felt. Den kan konsumere en strengverdi, men bare opp til en viss, hvis verdien overskrider, forbrukes et annet skjult felt.

Med ASP.NET er View State standardmetoden som følges for å lagre tilstanden for webapplikasjoner. Det er ganske enkelt å implementere og er ideelt for bruk når en bruker blir omdirigert til samme side, og derfor må vi holde informasjonen vedvarende til han selv omdirigerer til en annen side.

Fordeler med å bruke View State:

• Sikre den lagrede informasjonen fra lekmann ved å lagre den i hash-format. Faktisk for å holde det trygt fra hackere, kan du holde informasjonen i et kryptert format.
• Du kan tilpasse den når du ønsker det.
• Det er et flott alternativ der du vil implementere flere innlegg bak på en enkelt nettside.

Ulemper med å bruke View State:

• Det er ikke en sikker tilnærming, så sensitive data kan ikke lagres med den.
• Det kan forårsake overheadproblemer eller øke lastetiden ved å gjøre siden tung med mye informasjon.

2) Informasjonskapsler:

Det gir stor tilpasningsvennlighet ved klientens side, da informasjonskapsler lagres enten i minnet under klientens nettleserøkt eller blant annet klientens system. Faktisk kan man til og med lagre informasjonen knyttet til brukere og spore bruken. Den har en liten tekstfil med maksimal størrelse på 4096 byte, og en klientmaskin kan vise maksimalt 300 informasjonskapsler, mens et domene eller en server kan støtte maksimalt 20 informasjonskapsler.

Informasjonskapsler er videre delt inn i to kategorier, nemlig:

Vedvarende informasjonskapsel – Denne typen informasjonskapsler har en utløpsdato og lagres permanent på harddisken som er tilgjengelig på klientens maskin. Hvis det ikke er noen utløpsdato som tilsvarer vedvarende informasjonskapsel, vil den bli betraktet som en forbigående eller ikke-vedvarende informasjonskapsel.

Ikke-vedvarende informasjonskapsel eller forbigående informasjonskapsel – Siden denne typen informasjonskapsler lagres i nettleserminnet ved klientens ende i en midlertidig tidsperiode, etter den spesifikke tiden vil informasjonskapselen gå tapt.

Fordeler med å bruke informasjonskapsler:

• Den bruker bare noen få byte minne per informasjonskapsel.
• Enkel og ganske enkel å bruke.

Ulemper med å bruke informasjonskapsler:

• Det tilbyr ikke en sikker tilnærming da den lagrer informasjonen i klientens maskin og dermed er lagring av sensitive data ikke et levedyktig valg.
• Enhver bruker kan deaktivere informasjonskapslene ved å gjøre passende justeringer i nettleserinnstillingene.

3) Skjulte felt:

Dette er i utgangspunktet en serverkontroll som hjelper til med å administrere verdien på sidenivå, og den ligner litt på en visningstilstand. Dens verdi sendes via HTTP-skjemasamlingen, og sammen med den sendes også verdien til andre kontroller.

Fordeler med å bruke skjulte felt:

• Det er ganske enkelt å bruke.
• Siden verdien kun lagres på siden, brukes ikke serverressursene i det hele tatt. Dermed sparer de skjulte feltene serverressursene.

Ulemper med å bruke skjulte felt:

• Hvis flere skjulte felt skal implementeres på en side, vil det til slutt legge vekt på siden og gjøre den større og dermed øke sidens lastetid.
• Denne tilnærmingen er ikke ideell for lagring av sensitive data. Siden den ikke lagrer dataene i et kryptert eller hashet-format, er ikke denne teknikken sikker.

4 Søknadsstatus:

Denne tilstanden er perfekt for å lagre dataene som kreves for å få tilgang til gjennom hele applikasjonen. Den opptar serverressursene, ettersom den lagrer dataene i serverminnet. Applikasjonstilstanden er ikke begrenset til noen bestemt bruker eller økt, men den gjelder for alle økter og brukere. Men i dette tilfellet vil dataene bare beholdes så lenge applikasjonen kjører, så snart applikasjonen avsluttes eller startes på nytt, vil hele lagrede data gå tapt. Faktisk vil det også bli bortkastet når en webserver startes på nytt, ettersom dataene er lagret ved serverenden.

I Application State brukes et objekt av klassen HttpApplicationState til å lagre dataene. Denne klassen er en navngitt objektsamling, noe som betyr at den inkluderer data av enhver type. Det kan være en del av et nøkkel/verdi-par.

Fordeler med søknadstilstand:

• Søknadstilstanden har globalt omfang. Dataene kan nås når som helst når applikasjonen kjører.
• Det er ingen utløpsperiode som standard.

Ulemper med søknadstilstand:

• Applikasjonstilstand krever serverressurser for å lagre data. Dette kan føre til skalerbarhetsproblemer hvis det ikke håndteres riktig.
• Application State er ikke trådsikker, så vi må implementere låser.
• I tilfelle applikasjonsfeil eller omstart går alle lagrede data tapt.

Status for 5 økter:

Denne metoden brukes oftest av flere utviklere for å opprettholde applikasjonstilstanden. I denne tilnærmingen lagres verdien i form av ordboksamling, det vil si at den er sammenkoblet som nøkkel og verdi. Her brukes serverressursene i sin helhet til å lagre applikasjonens tilstand. Siden det lagrede ikke overføres til klientene, tilbyr denne teknikken en trygg og svært sikker metode.

I denne tilnærmingen genereres en separat økt med en unik ID for hver bruker. Siden denne IDen er lagret på klientens system, brukes informasjonskapsler til lagringen. Økten blir drept så snart brukeren logger ut av applikasjonen, og hvis han kommer tilbake til applikasjonen i fremtiden, opprettes en ny økt.

Den kan brukes i hvilken som helst av de fire modusene. Her er modusene:

• AV – For å deaktivere økten, det vil si hvis du ikke er interessert i å inkludere økttilstanden i applikasjonen din, kan du sette på AV-modus.
• InProc – Sesjonsvariabelen lagres i denne modusen som standardlager. Her lagres verdien i samme prosess som ASP.NET-applikasjonen faktisk kjører. Den gir dermed enestående ytelse.
• State Server – I denne modusen lagres dataene i en separat prosess i Windows-tjenesten. Den isolerer dermed de to prosessene, en der applikasjonen kjører og den andre der dataene lagres. Derfor er ytelsen ikke like god som i InProc-modus.
• SQL Server – Her lagres øktdata i SQL Server. Det er vanskelig å administrere i InProc-modus med flere servermaskiner. For det er det bedre å lagre dataene kun i SQL-serveren, det vil gjøre dataene sentralt tilgjengelige for alle maskinene. Denne modusen tilbyr maksimal sikkerhet, men den gir dårligere ytelse.

Disse fem er de mest brukte tilstandsadministrasjonsteknikkene for ASP.NET-applikasjoner. Integrer den teknikken i applikasjonen din som kan sikre fullstendig sikkerhet for dataene og rask ytelse.