web-dev-qa-db-fra.com

Utilisation par EF (entité framework) de l'instruction "using"

J'ai un projet sur MVC. Nous avons choisi EF pour nos transactions DB. Nous avons créé des gestionnaires pour la couche BLL. J'ai trouvé beaucoup d'exemples, où l'instruction "using" est utilisée, c'est-à-dire.

public Item GetItem(long itemId)
    {
        using (var db = new MyEntities())
        {
            return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault();
        }
    }

Ici, nous créons une nouvelle instance de DBcontext MyEntities(). Nous utilisons "using" afin de "assurer l'utilisation correcte des objets IDisposable."

Ce n'est qu'une méthode dans mon manager. Mais j'en ai plus de dix. Chaque fois que j'appelle une méthode du gestionnaire, j'utilise l'instruction "using" et je crée un autre DBcontext en mémoire. Quand le garbage collector (GC) les éliminera-t-il? Est-ce que quelqu'un sait?

Mais il existe une utilisation alternative des méthodes de gestion. Nous créons une variable globale:

private readonly MyEntities db = new MyEntities();

et utilisez DBcontext dans chaque méthode sans instruction "using". Et la méthode ressemble à ceci:

public Item GetItem(long itemId)
{
    return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault();
}

Des questions:

  1. Quelle est la bonne façon d'utiliser la variable DBcontext?
  2. Et si nous n'utilisions pas l'instruction "usage" (car cela affecte les performances) - GC fera tout pour cela?

Je suis un "débutant" dans l'utilisation d'EF et je n'ai toujours pas trouvé la réponse sans équivoque à cette question.

c#entity-frameworkgarbage-collectiondbcontextusing-statement
27
Pal

Je pense que vous en trouverez beaucoup suggérant ce style de motif. Pas seulement moi ou Henk gestion DBContext

  • Oui, idéalement en utilisant des instructions pour les sous-types DBContext
  • Des modèles d'unité de travail encore meilleurs qui sont gérés avec Using, qui ont un contexte et éliminent le contexte Juste 1 des nombreux exemples d'UoW, celui-ci de Tom Dykstra
  • Le gestionnaire d'unité de travail doit être Nouveau à chaque demande Http
  • Le contexte n'est PAS sûr pour les threads, alors assurez-vous que chaque thread a son propre contexte.
  • Laissez EF mettre les choses en cache dans les coulisses.
  • Tester les heures de création du contexte. après plusieurs requêtes Http. Avez-vous toujours une inquiétude?
  • Attendez-vous à des problèmes si vous stockez le contexte en statique. toute sorte d'accès simultané sera blessée et si vous utilisez des appels parallèles AJAX, supposez 90 +% de chances de problèmes si vous utilisez un seul contexte statique.

Pour quelques conseils de performance, vaut bien une lecture

13
phil soady

La manière appropriée ou la meilleure pratique d'utiliser la variable DBContext consiste à utiliser.

    using (var db = new MyEntities())
    {
        return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault();
    }

L'avantage est que beaucoup de choses se font automatiquement pour nous. Par exemple, une fois le bloc de code terminé, le disposer est appelé.

Par MSDN EF travaillant avec DbContext

La durée de vie du contexte commence lorsque l'instance est créée et se termine lorsque l'instance est supprimée ou récupérée. Utilisez using si vous souhaitez que toutes les ressources contrôlées par le contexte soient supprimées à la fin du bloc. Lorsque vous utilisez using, le compilateur crée automatiquement un bloc try/finally et les appels sont supprimés dans le bloc finally.

2
Catto