¿Debe el Contexto del marco de la entidad ingresar en la declaración de uso?

Question

El objeto de contexto de Entity Framework implementa un método Dispose() que "Libera los recursos utilizados por el contexto del objeto". ¿Qué es lo que realmente hace? ¿Sería algo malo ponerlo siempre en una declaración de {} uso? Lo he visto usar tanto con y sin la declaración de uso.

Específicamente voy a utilizar el contexto EF desde un método de servicio WCF, creo el contexto, hago un poco de linq y devuelvo la respuesta.

EDITAR: Parece que no soy el único que se pregunta sobre esto. Otra pregunta es qué está sucediendo realmente dentro del método Dispose(). Algunos dicen que cierra las conexiones, y algunos artículos dicen que no. ¿Cual es el trato?

Answer 1

Si crea un contexto, debe deshacerse de él más tarde. Si debe usar la instrucción using, depende del tiempo de vida del contexto.

1. Si crea el contexto de un método y utilizarlo sólo dentro de este método, que realmente debe utilizar la instrucción using porque le da el control de excepciones sin ningún código adicional.

2. Si se utiliza el contexto para un período más largo - que es el tiempo de vida no está obligado por el tiempo de ejecución de un método - no se puede utilizar la instrucción using y hay que llamar Dispose() ti mismo y tener cuidado de que siempre llámalo.

¿Qué hace Dispose() para un contexto de objeto?

No miré el código, pero al menos espero que cierre la conexión de la base de datos con sus sockets subyacentes o con los recursos que haya utilizado el mecanismo de transporte.

Answer 2

Siempre, si instancia una clase que implementa IDisposable, entonces usted es responsable de llamar a Dispose. En todos los casos menos uno, esto significa un usando el bloque.

Answer 3

Dado que no sabe cuándo el recolector de basura dispone de un artículo, siempre es bueno envolver objetos que implementen IDisposable en un usando el bloque si sabe cuándo ha terminado con él.

Answer 4

Cuando deseche, el ObjectContext dispone otros objetos propios.

Incluye cosas como la EntityConnection que envuelve la conexión real de la base de datos, es decir, una conexión Sql.

Así que 'si' la conexión Sql está abierta, se cerrará cuando elimine el ObjectContext.

Answer 5

por Progamming Entity Framework: "Puede eliminar explícitamente el ObjectContext o esperar a que el recolector de basura haga el trabajo".

En resumen, aunque no se requiere la instrucción de uso, es recomendable si se completa el uso del ObjectContext, ya que el recurso se libera inmediatamente en lugar de esperar la recolección de elementos no utilizados.

Answer 6

He notado (aunque en una sola aplicación) que la eliminación explícita causaba abortar las excepciones en mscorlib que están atrapadas antes del código de la aplicación, pero al menos en mi caso resulta en un golpe de rendimiento notable. No he hecho ninguna investigación significativa sobre el tema, pero probablemente algo que valga la pena considerar si estás haciendo esto. Simplemente mire su salida DEBUG para ver si está obteniendo el mismo resultado.

Answer 7

Si Dispose cierra la conexión a DB, es una mala idea llamarlo. Por ejemplo, en las conexiones ADO.NET están en el grupo de conexiones y nunca se cierran antes de que se agote el tiempo de espera o se detenga el grupo de aplicaciones.

Answer 8

realmente Probé esta cosa tanto para ADO.net y v.6 EF y vi conexiones en la tabla SQL

select * from sys.dm_exec_connections 

Métodos a ensayar veía así:

1) ADO.net con usando

using(var Connection = new SqlConnection(conString)) 
    { 
    using (var command = new SqlCommand(queryString, Connection)) 
    {  
     Connection.Open(); 
     command.ExecuteNonQueryReader(); 
     throw new Exception() // Connections were closed after unit-test had been 
     //finished. Expected behaviour 
    } 
    } 

2) ADO.net sin que usando

var Connection = new SqlConnection(conString); 
using (var command = new SqlCommand(queryString, Connection)) 
{ 
    Connection.Open(); 
    command.ExecuteNonQueryReader(); 
    throw new Exception() // Connections were NOT closed after unit-test had been finished 

    finished. I closed them manually via SQL. Expected behaviour 
    } 

1) EF con usar.

using (var ctx = new TestDBContext()) 
    { 
     ctx.Items.Add(item); 
     ctx.SaveChanges(); 
     throw new Exception() // Connections were closed, as expected. 

    } 

2) EF sin utilizar

var ctx = new TestDBContext();    
ctx.Items.Add(item); 
ctx.SaveChanges(); 
throw new Exception() // Connections WERE successfully closed, as NOT expected. 

No sé por qué es así, pero EF conexiones cerradas automáticamente. Además, todos los patrones de repositorio y UnitOfWork que usan EF no usan. Es muy extraño para mí, porque DBContext es de tipo Desechable, pero es un hecho.

Tal vez en Microsoft hicieron algo nuevo para el manejo?

Answer 9

EF5 y antes de la versión

using { ... 
      // connecction open here. 

      ... 
      context.Blogs.Add(blog); 
      context.SaveChanges(); // query etc now opens and immediately closes 

      ... 
      context.Blogs.Add(blog); 
      context.SaveChanges(); // query etc now opens and immediately closes 
    } 

EF6 y después de la versión

using { 
     // connecction open here. 

     ... 
     context.Blogs.Add(blog); 
     context.SaveChanges(); 

     // The underlying store connection remains open for the next operation 

     ... 
     context.Blogs.Add(blog); 
     context.SaveChanges(); 

     // The underlying store connection is still open 

    } // The context is disposed – so now the underlying store connection is closed 

Referencia: http://msdn.microsoft.com/en-us/data/dn456849#open5