180 votes

Sont des instances de la classe statique unique à une demande ou d’un serveur dans ASP.NET ?

Sur un ASP.NET site web, sont statiques des classes uniques à chaque requête web, ou sont-ils instancié à chaque fois que nécessaire et GCed chaque fois que le GC décide d'aliénés?

La raison pour laquelle je demande c'est parce que j'ai écrit certains de classes statiques avant en C# et le comportement est différent que je l'aurais imaginé. Je me serais attendu de classes statiques être unique pour chaque demande, mais il ne semble pas comme c'est le cas.

Si ils ne sont pas uniques à chaque demande, est-il un moyen pour leur permettre d'être?

Mise à JOUR:
La réponse driis m'a donné était exactement ce dont j'avais besoin. J'étais déjà en utilisant une classe singleton, cependant, il a été à l'aide d'une instance statique et, par conséquent, était partagée entre les demandes, même si les utilisateurs étaient différents, qui dans ce cas était une mauvaise chose. À l'aide de HttpContext.Current.Items résout mon problème à la perfection. Pour tous ceux qui bute sur cette question dans l'avenir, voici ma mise en œuvre simplifiée et raccourcie de sorte qu'il est facile de comprendre le modèle:

using System.Collections;
using System.Web;

public class GloballyAccessibleClass
{
    private GloballyAccessibleClass() { }

    public static GloballyAccessibleClass Instance
    {
        get
        {
            IDictionary items = HttpContext.Current.Items;
            if(!items.Contains("TheInstance"))
            {
                items["TheInstance"] = new GloballyAccessibleClass();
            }
            return items["TheInstance"] as GloballyAccessibleClass;
        }
    }
}

143voto

driis Points 70872

Vos classes statiques et statique des champs d'instance sont partagés entre toutes les requêtes de l'application, et a la même durée de vie que le domaine d'application. Par conséquent, vous devez être prudent lors de l'utilisation statique instances, car vous pourriez avoir des problèmes de synchronisation et la comme. Aussi garder à l'esprit que statique instances ne seront pas GC ed avant l'application de la piscine est recyclé, et donc tout ce qui est référencé par l'instance statique, ne sera pas GC ed. Cela peut conduire à l'utilisation de la mémoire de problèmes.

Si vous avez besoin d'une instance avec la même durée de vie d'une requête, je vous suggère d'utiliser l' HttpContext.Current.Items de la collecte. C'est par la conception censé être un endroit pour stocker des choses que vous avez besoin d'éparpiller la demande. Pour une plus jolie présentation et la lisibilité, vous pouvez utiliser le pattern Singleton pour vous aider à gérer ces éléments. Il suffit de créer une classe Singleton qui stocke son instance en HttpContext.Current.Items. (Dans ma bibliothèque commune pour ASP.NET j'ai un générique SingletonRequest classe et à cette fin).

27voto

Les membres statiques ont un champ d'application de l'actuel processus de travail seulement, de sorte qu'il n'a rien à voir avec les demandes, parce que les différentes demandes peuvent ou ne peuvent pas être traités par le même processus de travail.

  • Afin de partager les données avec un utilisateur spécifique, et entre les requêtes, utilisez HttpContext.Actuel.Session.
  • Afin de partager les données au sein d'une demande spécifique, utilisez HttpContext.Actuel.Éléments.
  • Afin de partager des données à travers l'ensemble de l'application, soit de créer un mécanisme pour que, ou de configurer IIS pour travailler avec un seul processus, et d'écrire un singleton / utiliser l'Application.

Par ailleurs, la valeur par défaut du nombre de processus de travail est de 1, c'est pourquoi le web est plein de gens qui pensent que des membres statiques ont un champ d'application de l'ensemble de l'application.

11voto

Sijin Points 3682

Depuis les types sont contenues dans un domaine d'application, je l'espère les classes statiques d'être présent aussi longtemps que le domaine d'application n'est pas recyclé, ou si la demande sera servi par un autre domaine d'application.

Je peux penser à plusieurs façons de créer des objets spécifiques à une demande particulière dépend de ce que vous voulez faire, pour par exemple vous pouvez instancier l'objet dans l'Application.BeginRequest et puis le stocker dans l'objet HttpRequest de sorte qu'il peut être consulté par tous les objets dans le pipeline de traitement de demande.

4voto

rp. Points 9997

S'ils ne sont pas uniques à chaque demande, existe-t-il un moyen de les autoriser?

Nan. Les membres statiques appartiennent au processus ASP.NET et sont partagés par tous les utilisateurs de l'application Web. Vous devrez vous tourner vers d'autres techniques de gestion de session, telles que les variables de session.

0voto

Sklivvz Points 16412

Normalement statique de méthodes, de propriétés et de classes, qui sont communs à l' Application . Tant que l'application des vies, ils sont partagés.

Vous pouvez spécifier un comportement différent à l'aide de la ThreadStatic d'attribut. Dans ce cas, elles seront spécifiques à ce thread, qui, je pense, est spécifique pour chaque demande.
Je ne vous conseille pas ce qu'elle semble être trop compliqué.

Vous pouvez utiliser HttpContext.Current.Items pour définir des trucs pour une demande, ou HttpContext.Current.Session pour définir des trucs pour un utilisateur (sur demande).

Toutefois, en général, à moins d'avoir à utiliser des choses comme Server.Transfer, la meilleure façon est essentiellement de créer des choses une fois et puis les passer explicitement par l'invocation de méthode.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X