Crear instancias de un contexto en LINQ para entidades

Question

He visto dos maneras diferentes que los programadores abordan al crear un contexto de entidad en su código.

El primero es así, y puede encontrarlo en todos los ejemplos de código de MSDN:

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

El segundo es crear el contexto como un atributo privado en alguna clase que encapsule su lógica de negocios. Entonces tendrías algo como:

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
        }
}

¿Qué camino es más eficiente?

Suponga que tiene dos métodos, uno llamado DoSomething1 () y otro llamado DoSomething2 (), y ambos métodos incorporan la instrucción de uso para abrir el contexto y hacer lo que sea con él. Si llamaras a un método después del otro, ¿habría alguna sobrecarga superflua, ya que esencialmente ambos métodos crean el contexto y luego lo limpian cuando terminan? ¿A diferencia de tener solo un atributo privado que se crea cuando se instancia una clase de objeto y luego se limpia cuando el objeto se sale del alcance?

Answer 1

La creación de un nuevo ObjectContext cada vez implica "algunos" gastos generales. Esencialmente, la sobrecarga involucrada es copiar metadatos de una caché global en metadatos asociados con el ObjectContext específico.

Esta sobrecarga es relativamente menor, por lo que a menudo no vale la pena preocuparse, especialmente cuando se considera la seguridad adicional inherente al patrón de uso.

Para mí, la opción que elijas depende de cosas como:

1. ¿Cuánto tiempo vivió es tu clase de envoltura es probable que sea? Si vive por un mucho tiempo el ObjectContext podría crecer para contener muchas entidades ralentizando con el tiempo. Entonces un nuevo ObjectContext cada vez podría ser un buena idea.
2. Son llamadas a la métodos en su clase de envoltura sincronizado? El ObjectContext La clase en sí no es segura para hilos, así que si usa el segundo patrón que necesita para asegurarse de que su clase de envoltura / el repositorio es seguro para hilos si esperar múltiples hilos para llamarlo.
3. ¿Son los métodos esencialmente ¿no relacionado? Si es así, puede obtener efectos secundarios inesperados si comparten un contexto entre los métodos.

En general, mi recomendación es que si los métodos no tienen estado, es decir, disparar y olvidar un nuevo contexto para cada método probablemente sea una buena idea.

Sin embargo, si tiene una forma de estado relativamente corta o algo así, tal vez un contexto compartido sea una mejor idea.

ACTUALIZACIÓN: Me he tomado el tiempo de armar una respuesta más completa

Answer 2

La segunda opción en realidad no se limpia después de sí misma si eso es lo que quieres decir. Prefiero usar la versión ObjectContext cada vez porque no tengo que deshacerme de ella después. Sin embargo, no estoy seguro de haber respondido bien la pregunta ... Demasiadas horas programando hoy.

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;
    }
}

Luego, para usar este repositorio, hago algo como:

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