J'ai une application Web où je voudrais tirer les paramètres utilisateur d'une base de données et les stocker pour un accès global. Serait-il plus logique de stocker les données dans un singleton ou un objet de session? Quelle est la différence entre les deux?
est-il préférable de stocker les données comme référence d'objet ou de la rompre dans des objets de type de valeur (INTS et Strings)?
5 Réponses :
session. C'est ce que c'est pour. La session est stockée dans le cache global (fondamentalement un singleton), clavée par l'ID de session. De cette façon, vous n'obtenez que les données de la session d'intérêt. L'utilisation d'un singleton reproduirait essentiellement le cache global et vous devez réinventer le mécanisme pour récupérer des données pour chaque session de manière indépendante.
Allez-y et stockez l'objet. Laissez la séance s'inquiéter de la sérialiser à quelque chose qui peut être restauré. Soyez prudent, cependant, avec ce que vous avez mis à la session. Vous ne voulez pas stocker trop de données là-bas ou vous utiliserez beaucoup de mémoire (en supposant un cache en mémoire).
Si ces paramètres seront utilisés pour tous les utilisateurs du site, mettez-les dans un singleton ou dans le cache d'applications. S'ils sont spécifiques à chaque utilisateur, mettez-les en session.
Utilisez des références d'objet lors de l'ajout à l'application ou au cache de session - je pense que les types de valeur seront en boîte afin qu'ils ressemblent à des objets dans le cache. Si vous utilisez un singleton, cela pourrait aller de toute façon.
objet de session, définitivement.
Singletons existent au niveau du processus. Cela signifie que si vous avez 20 utilisateurs accédant à votre site à un moment donné, ils utilisent le même objet Singleton. Il est difficile de s'habituer à ce concept si vous ne faites pas beaucoup de développement Web.
Les sessions existent au niveau de l'utilisateur. Cela signifie que vous pouvez stocker des données par utilisateur et non par processus.
L'état de l'application est un excellent exemple de Un singleton au niveau du processus ASP .NET. Toute paire de valeurs de clé de poids léger destinée à tous les utilisateurs du site Web peut être stockée. Ces paires de la valeur clé resteront accessibles dans des appels Web. Pour des objets intensifs lourds ou des ressources, il faut envisager d'utiliser cache à la place .
Parfois, j'aime la méthode ci-dessous. Il s'occupe des problèmes avec des chaînes magiques et des variables de session non définies. Il exécute également le singleton au niveau de la session plutôt que le niveau d'application.
public static SessionHandler GetInstance()
{
if (HttpContext.Current.Session["SessionHandler"] == null)
{
HttpContext.Current.Session["SessionHandler"] = new SessionHandler();
}
return (SessionHandler)HttpContext.Current.Session["SessionHandler"];
}
Ceci est extrait d'un ancien document, mais il est toujours très valide et travaille un régal ... Je vais mettre le contenu du lien ici, surtout parce que c'est un ancien lien qui peut disparaître. prise d'ici.
arrière-plan strong> p> L'objet de session Dans ASP.NET, vous pouvez utiliser pour stocker des informations spécifiques à un utilisateur individuel du site. La session est indexée par un nom de clé et lorsqu'elle est utilisée directement de manière à ce que cela puisse conduire à un grand nombre de noms de session individuels. Une approche alternative consiste à créer un objet singleton pour grouper des éléments associés et à stocker cet objet avec un nom de clé donné. Le "singleton" est un modèle de conception commun qui spécifie comment s'assurer que seule une seule instance d'une classe existe à tout moment. P> Avantages des objets de session singleton strong> p> P> Inconvénients des objets de session singleton strong> p> plus difficile à voir le nombre d'éléments individuels en session
Les résultats de la trace ASP.NET ne montrent pas les valeurs à l'intérieur de l'objet
Dégradation des performances Lors de l'utilisation du stockage de l'état de la session de processus (affectant la sérialisation) p> strong> fort> p> La première étape de mise en œuvre consiste à créer un fichier de classe qui représente la logique regroupement d'éléments qui doivent être stockés ensemble dans l'objet unique. Ce qui suit est une classe d'échantillons qui démontre la technique: p> une page qui souhaite utiliser cet objet effectue simplement ce qui suit: P>
public static void Dispose()
{
//Cleanup this object so that GC can reclaim space
System.Web.HttpContext.Current.Session.Remove(SESSION_SINGLETON);
}