Instanciation d'un contexte dans LINQ aux entités

Question

J'ai vu deux manières différentes que les programmeurs abordent lors de la création d'un contexte d'entité dans leur code.

Le premier est comme tel et vous pouvez le trouver partout dans les exemples de code MSDN:

public void DoSomething() {
     using (TaxableEducationEntities context = new TaxableEducationEntities()) {
          // business logic and whatever else
     }
}

La seconde consiste à créer le contexte en tant qu'attribut privé dans une classe qui encapsule votre logique métier. Donc, vous auriez quelque chose comme:

public class Education_LINQ {

        private TaxableEducationEntities context = new TaxableEducationEntities();

        public void DoSomething() {
            var result = from a in context.luAction
                         select a;

            // business logic and whatever else
        }
}

Quel est le moyen le plus efficace?

Supposons que vous avez deux méthodes, l'une appelée DoSomething1 () et une autre appelée DoSomething2 (), et que les deux méthodes incorporent l'instruction using pour ouvrir le contexte et tout faire avec. Si vous appeliez une méthode après l'autre, y aurait-il une surcharge superflue, puisque les deux méthodes créent essentiellement le contexte et le nettoient ensuite? Au lieu d’avoir un seul attribut privé créé lorsqu’un objet de classe est instancié, puis nettoyé à son tour lorsque l’objet sort de la portée?

Answer 1

La création d'un nouveau ObjectContext implique à chaque fois "quelques" frais généraux. La surcharge impliquée consiste essentiellement à copier les métadonnées d'un cache global dans des métadonnées associées au ObjectContext spécifique.

Ces frais généraux sont relativement mineurs, il est donc souvent inutile de s’inquiéter, en particulier si l’on prend en compte la sécurité supplémentaire inhérente au motif d’utilisation.

Pour moi, l'option que vous choisissez dépend de facteurs tels que:

1. Combien de temps a vécu votre classe d'emballage susceptible d'être? S'il vit pour un longtemps le ObjectContext pourrait grandir pour contenir beaucoup d'entités ralentir avec le temps. Donc une nouvelle ObjectContext à chaque fois peut être un bonne idée.
2. Les appels à la méthodes sur votre classe d'emballage synchronisé? L'objetContext classe elle-même n'est pas threadsafe si vous utilisez le second motif dont vous avez besoin pour vous assurer que votre classe d'emballage / référentiel est thread-safe si vous attendez-vous à ce que plusieurs threads l'appellent.
3. Les méthodes sont-elles essentiellement sans lien? Si tel est le cas, vous pourriez avoir des effets secondaires inattendus s’ils partagent un même contexte entre les méthodes.

En général, ma recommandation est que, si les méthodes sont sans état, c’est-à-dire qu’il est préférable d’utiliser un nouveau contexte pour chaque méthode.

Si toutefois vous avez une forme dynamique relativement courte à vie ou quelque chose, alors un contexte partagé est peut-être une meilleure idée.

UPDATE: j'ai pris le temps de mettre en place une réponse plus complète

Answer 2

La deuxième option ne nettoie pas si c'est ce que vous voulez dire. Je préfère utiliser la version d'ObjectContext à chaque fois, car je n'ai pas à la disposer par la suite. Je ne suis pas sûr d’avoir bien compris la question ... Trop d’heures de programmation aujourd’hui.

public class UserManagerRepository : IUserManagerRepository, IDisposable
{
    private readonly Entities _context = new Entities();
    private bool _disposed;

    public User Create(User user, int countryId)
    {
        user.Country = GetCountry(countryId);
        _context.AddToUser(user);
        _context.SaveChanges();
        return user;
    }
}

Ensuite, pour utiliser ce référentiel, je fais quelque chose comme:

using(var repository = new UserManagerRepository())
{
    repository.Create(user);
}