Cache VS Session VS cookies?

Question

Quelles sont les choses à faire et à ne pas faire à propos de Cache VS Session VS Cookies?

Par exemple: Im en utilisant les variables de Session beaucoup et ont parfois problème dans la réservation-demande lorsque les utilisateurs commence à commander des produits et puis s'en va pour le déjeuner et de revenir quelques heures plus tard et continuer la réservation. - Je stocker la réservation de la session jusqu'à l'utilisateur de confirmer ou d'annuler la réservation, afin que je n'ai pas besoin de parler de la base de données et gérer à mi-chemin des réservations dans la base de données lorsque les utilisateurs de simplement cliquer sur le X dans le navigateur et ne revient jamais.

Devrais-je plutôt utiliser cashe ou des cookies ou toute combinaison de tous les ci-dessus pour cela?

(J'ai aussi eu des problèmes, lorsqu'il y a une erreur dans l'application de la sessison-objet se réinitialise et j'ai eu beaucoup plus de problèmes à cause de ça)

Im surtout de faire du bureau de programmation et de sentir que je manque beaucoup de connaissances ici, donc n'importe qui peut s'étendre sur l'endroit où l'utilisation du Cache, de la Session, les cookies (ou db)

Edit: D'après les réponses, il semble qu'une combinaison de la DB et des biscuits est ce que je veux.

1. J'ai pour stocker la réservation dans la base de données connecté à une session-id
2. stocker l'identifiant la session dans un cookie (crypté).
3. Chaque chargement de page vérification du cookie et de chercher de la réservation, à partir de la base de données
4. J'ai une procédure de dépollution qui s'exécute une fois par semaine qui efface unfinnished les réservations.

Je ne peux pas stocker la réservation d'un cookie, car l'utilisateur peut alors modifier les prix et d'autres données sensibles et j'ai dû valider tout (cant faire confiance aux données).

Ai-je eu raison?

Et grand merci pour les explications à vous tous!

Answer 1

La gestion de l'état est une chose essentielle à maîtriser lors de la venue de monde de Web à partir d'une application de bureau de point de vue.

• Session est utilisé pour stocker par utilisateur de l'information pour le site Web en cours de session sur le serveur. Il prend en charge l'utilisation d'un serveur de base de données que le magasin principal.
• Cookie doit être utilisé pour stocker par utilisateur de l'information pour le site Web en cours de session ou persistants de l'information sur le client, donc le client a le contrôle sur le contenu d'un cookie.
• Cache objet est partagé entre plusieurs utilisateurs en une seule application. Son but principal est de mettre en cache des données à partir d'une banque de données et ne doit pas être utilisé comme stockage principal. Il prend en charge automatique d'annulation de fonctionnalités.
• Application objet est partagé entre les utilisateurs pour stocker l'ensemble de l'application de l'état et doit être utilisé en conséquence.

Si votre application est utilisée par un nombre d'utilisateurs non authentifiés, je vous propose de stocker les données dans un cookie. Si elle nécessite une authentification, vous pouvez stocker les données dans la base de données manuellement ou à l'utilisation ASP.NET profil de fonctions de gestion.

Answer 2

Le Web est, par nature, modèle déconnecté et aucune des solutions mentionnées (Session, de l'Application, Cache, ...) sont assez fiables. Session timeout, processus de travail est recyclé, etc.

Si vous avez vraiment besoin pour stocker les utilisateurs de progrès, de manière fiable et à travers de longues périodes, la base de données est votre seule solution. Si vous avez le profil de l'utilisateur (si l'utilisateur doit se connecter), puis c'est simple. Si pas, de générer un Identifiant unique, de le stocker dans le cookie (ou l'URL) et le suivi de l'utilisateur sur la base de cette identification.

Juste assurez-vous que l'Id est chiffré puis encodé en base64 de la chaîne, et pas seulement une valeur numérique.

EDIT:

Après votre explication complémentaire dans la question d'origine et de commentaires de Mehrdad Afshari, la bonne solution pour vous serait de Session d'utilisation mais définir le stockage de Sql Server au lieu de InProc.

Voici plus de détails et les instructions sur comment le configurer: http://msdn.microsoft.com/en-us/library/ms178586.aspx

Avoir à l'esprit que vous aurez TOUJOURS les délais d'expiration de session, mais ils vont survivre à la demande de la piscine recycle, même redémarrage du serveur.

Si vous avez vraiment besoin d'un stockage permanent, la solution personnalisée avec la base de données, comme je l'ai d'abord énoncé est la seule solution.

Answer 3

La Session est stocké sur le serveur, le temps par défaut dans 20 minutes (C'est réglable). Je voudrais stocker cela dans un cookie, ou dans l'état d'affichage(si disponible) pour éviter le délai d'attente.

Si votre état est stocké InProc(la configuration par défaut), puis d'avoir plus d'un serveur dans une ferme va vous causer des problèmes, à moins que vous avez mis en place une sorte de "collant session" qui va garder les utilisateurs sur le même serveur dans la batterie de serveurs pour les appels suivants.

J'essaie d'éviter de session lorsque cela est possible(met une charge supplémentaire et l'utilisation de la mémoire sur le serveur), et de garder l'état d'affichage éteint dès que possible afin de garder la taille de la page faible. Les Cookies sont souvent les plus légers option, mais vos utilisateurs pourraient avoir cette désactivé et vous aurez besoin d'un mode de secours qui permet encore à utiliser le site.

Modifier (ajout de précisions en fonction de la réponse du demandeur):

Viewstate est stocké dans un champ caché, et est une représentation sérialisée de tous les objets dans l'état d'affichage de stockage. L'état d'affichage est automatiquement utilisé pour stocker la page de l'état, mais vous pouvez ajouter explicitement et de récupérer vos propres objets et de Viewstate par programmation si vous choisissez de.

Alors oui, les jeux de données peuvent être stockés dans l'état d'affichage.

Answer 4

D'abord les cookies sont utilisés par session : le serveur ne sait qui est votre utilisateur grâce au cookie qui est échangé entre le client et le serveur à chaque requête (cela fonctionne avec les en-têtes HTTP set-cookie et cookie).

La vraie question est : Si vous souhaitez stocker des informations de l'utilisateur lors de la navigation session d'UTILISATION. Si votre client ne prennent pas en charge les cookies, vous pouvez décider de stocker des cookies à l'intérieur de chaque demande, encodés dans l'URL (le serveur va utiliser l'URL au lieu de le cookie de trouver la bonne session de la demande).

Alors considérez où vous souhaitez stocker votre session : si votre site doit avoir une haute disponibilité et haute performance, vous ne devez pas stocker session à l'intérieur du processus, mais à l'intérieur d'une base de données. De cette façon vous serez en mesure de partager le travail entre plusieurs serveur web. Mais vous perdrez dans la simplicité (car les objets que vous stockez dans votre session doit être sérialisable), et vous avez plus d'un aller-retour entre votre serveur web et votre serveur de base de données.

Answer 5

Vous ne devez pas utiliser le Cache-objet pour mettre en cache les données de session, pour le cache est partagé entre tous les utilisateurs. Au lieu de cela, vous pourriez utiliser Asp.Net les propriétés de Profil pour stocker vos données, ou vous pouvez ajouter un gestionnaire d'événements pour l'événement Session_End et stocker les données si l'utilisateur quitte l'ordinateur pendant trop longtemps.