Cache VS Session VS cookies?

Question

Quali sono le cose da fare e da non fare sui cookie di Cache VS Session VS?

Ad esempio:
Utilizzo molto variabili di sessione e talvolta ho problemi in un'applicazione di prenotazione quando gli utenti iniziano a ordinare prodotti e poi vanno a pranzo e tornano qualche ora dopo e continuano la prenotazione. Conservo la prenotazione nella sessione fino a quando l'utente conferma o interrompe la prenotazione, quindi non ho bisogno di parlare al database e gestire le prenotazioni a metà nel database quando gli utenti fanno semplicemente clic sulla X nel browser e non tornano mai indietro.

Devo utilizzare invece cache o cookie o una combinazione per questo?

(anche se c'è qualche errore nella app, la sessione-oggetto si resetta e ottengo più problemi a causa di questo)

Sono per lo più facendo desktop programmazione e sentire mi manca un sacco di conoscenza qui così chi può espandersi su dove utilizzare cache, sessione, cookie (o ter) sarebbe apprezzato

Edit: Dalle risposte sembra che una combinazione di dB e biscotti è quello che voglio.

1. devo conservare la prenotazione nel database collegato ad un session-id
2. Conservare il session-id in un cookie (criptato).
3. Ogni caricamento di pagina controlla il cookie e preleva la prenotazione dal database
4. Ho una procedura di pulizia che viene eseguita una volta alla settimana che cancella le prenotazioni non completate.

Non riesco a memorizzare la prenotazione come cookie perché l'utente può modificare i prezzi e altri dati sensibili e ho dovuto convalidare tutto (non posso fidarmi dei dati).

Ho capito bene?

E grazie per le grandi spiegazioni a tutti voi!

Answer 1

La gestione dello stato è una cosa fondamentale da padroneggiare quando si arriva al mondo Web da una prospettiva di applicazione desktop.

• Session viene utilizzato per memorizzare per utente informazioni per la sessione Web corrente sul server. Supporta l'utilizzo di un server di database come archivio back-end.
• Cookie dovrebbe essere utilizzato per memorizzare per utente informazioni per la sessione Web corrente o persistente informazioni sul cliente , pertanto cliente ha il controllo dei contenuti di un cookie.
• Cache l'oggetto è condiviso tra utenti in una singola applicazione. Il suo scopo principale è quello di memorizzare nella cache i dati da un archivio dati e non deve essere utilizzato come archivio principale. Supporta le funzioni di annullamento automatico.
• Application l'oggetto è condiviso tra gli utenti per memorizzare lo stato a livello di applicazione e deve essere utilizzato di conseguenza.

Se la tua applicazione è utilizzata da un numero di utenti non autenticati, ti suggerisco di memorizzare i dati in un cookie. Se richiede l'autenticazione, è possibile memorizzare i dati nel DB manualmente o utilizzare le funzionalità di gestione del profilo di ASP.NET.

Answer 2

La sessione è archiviata sul server e scadrà automaticamente per impostazione predefinita in 20 minuti (è regolabile). Lo memorizzerei in un cookie o in viewstate (se disponibile) per evitare il timeout.

Se il tuo stato è memorizzato InProc (l'impostazione predefinita), quindi avere più di un server in una fattoria causerà problemi anche se non hai implementato una sorta di "sessione adesiva" che manterrà l'utente sul stesso server nella farm per le chiamate successive.

Cerco di evitare di sessione quando possibile (mette carico supplementare e l'utilizzo della memoria sul server), e mantenere ViewState spento quando possibile per mantenere le dimensioni della pagina bassa. I cookie sono spesso l'opzione più leggera, ma i tuoi utenti potrebbero averla disattivata e avrai bisogno di una modalità fallback che permetta comunque loro di utilizzare il sito.

Modifica (l'aggiunta di un chiarimento in base alla risposta da richiedente):

Viewstate è memorizzato in un campo nascosto, ed è una rappresentazione serializzata di tutti gli oggetti in deposito Viewstate. Viewstate viene utilizzato automaticamente per memorizzare lo stato della pagina, ma è possibile aggiungere e recuperare in modo esplicito i propri oggetti da e verso Viewstate in modo programmatico se si sceglie di farlo.

Quindi sì, i set di dati possono essere memorizzati in Viewstate.

Answer 3

Il Web è per sua natura un modello disconnesso e nessuna delle opzioni menzionate (Sessione, Applicazione, Cache, ...) è sufficientemente affidabile. Timeout della sessione, riciclo dei processi di lavoro, ecc.

Se è davvero necessario archiviare l'avanzamento degli utenti, in modo affidabile e per periodi prolungati, il database è l'unica soluzione. Se hai un profilo utenti (se l'utente deve accedere), allora è semplice. In caso contrario, generare un ID univoco, memorizzarlo nel cookie (o URL) e tracciare l'utente in base a tale identificazione.

Assicurati solo che l'ID sia crittografato e quindi stringa codificata in base 64 e non solo un valore numerico.

EDIT:

Dopo la spiegazione aggiuntiva nella domanda originale e commento da Mehrdad Afshari, buona soluzione per voi sarebbe quella di utilizzare sessione, ma impostare la memorizzazione a SQL Server invece di InProc.

Ecco maggiori dettagli e istruzioni su come configurarlo: http://msdn.microsoft.com/en-us/library/ms178586.aspx

avere in mente che si avrà ancora i timeout di sessione, ma sopravviverà pool di applicazioni ricicla, anche riavvio del server.

Se si ha veramente bisogno di una memoria permanente, la soluzione personalizzata con il database, come originariamente delineato, è l'unica soluzione.

Answer 4

Non si deve utilizzare l'oggetto Cache per memorizzare nella cache i dati della sessione, poiché la cache è condivisa tra tutti gli utenti. Invece è possibile utilizzare Asp.Net Profile properties per memorizzare i dati o aggiungere un gestore di eventi all'evento Session_End e archiviare i dati se l'utente lascia il computer troppo a lungo.

Answer 5

Per prima cosa devi sapere! I cookie vengono utilizzati dalla sessione! Il server sa chi è il tuo utente grazie al cookie che viene scambiato tra il client e il server ogni richiesta (questo funziona con le intestazioni HTTP set-cookie e cookie).

La vera domanda è:

• Se si desidera memorizzare le informazioni dell'utente durante la navigazione, allora si dovrebbe usare sessione.
  
• Se il client non supporta i cookie, quindi è possibile decidere di memorizzare un cookie all'interno di ciascuna richiesta, codificato nell'URL (il server utilizzerà l'URL anziché il cookie per trovare la sessione corretta per la richiesta) .

quindi prendere in considerazione in cui si desidera memorizzare la sessione:
Se il tuo sito deve avere elevata disponibilità e prestazioni elevate, allora non è necessario memorizzare sessione all'interno del processo, ma all'interno di un database. In questo modo sarai in grado di condividere il lavoro tra diversi server web. Ma perderete in semplicità (perché gli oggetti che memorizzate nella vostra sessione devono essere serializzabili) e avete ancora un round trip tra il vostro server web e il vostro server di database.

Answer 6

Cookies sono memorizzate nel browser come un file di testo format.It vengono memorizzati quantità limite di data.It è solo permettendo 4KB [4096bytes] .Non sta tenendo la variabile multipla nei cookie.

possiamo Accesso ai valori biscotti in easily.So è meno sicuro funzione .La setcookie() deve apparire prima del tag.

Le sessioni vengono memorizzate sul lato server. È memorizzata una quantità illimitata di dati. È in grado di contenere la variabile multipla nelle sessioni. non possiamo accedere facilmente ai valori dei cookie. Quindi è più sicuro.

vicini:cache-vs-session-vs-cookies