c# - visual - ¿Hay algún efecto secundario de regresar desde el interior de una declaración using()?

visual c# using

Question

Devolver un valor de método desde dentro de una sentencia using que obtiene un DataContext parece funcionar siempre bien , así:

public static Transaction GetMostRecentTransaction(int singleId)
{
using (var db = new DataClasses1DataContext())
{
var transaction = (from t in db.Transactions
orderby t.WhenCreated descending
where t.Id == singleId
select t).SingleOrDefault();
return transaction;
}
}

Pero siempre siento que debería cerrar algo antes de salir de los corchetes, por ejemplo, definiendo la transacción antes de la instrucción de uso, obtengo su valor dentro de los corchetes y luego regreso después de los corchetes.

¿La definición y devolución de la variable fuera de los corchetes de uso sería una mejor práctica o conservaría los recursos de alguna manera?

Answer 1

Creo que es todo lo mismo. No hay nada malo en el código. Al .NET framework no le importaría dónde se crea el objeto. Lo que importa es si se hace referencia o no.

Answer 2

Echa un vistazo a esto

Comprender el enunciado ''usar'' en C #

El CLR convierte su código en MSIL. Y la declaración de uso se traduce en un intento y finalmente bloquea. Así es como se representa la sentencia using en IL. Una declaración de uso se traduce en tres partes: adquisición, uso y eliminación. El recurso se adquiere primero, luego el uso se incluye en una declaración try con una cláusula finally. El objeto luego se elimina en la cláusula finally.

Answer 3

No hay efectos secundarios de regresar desde dentro de una declaración using() .

Si hace el código más legible es otra discusión.

Answer 4

No, creo que está más claro de esta manera. No se preocupe, Dispose seguirá llamándose "en el camino de salida", y solo después de que el valor de retorno se evalúe por completo. Si se lanza una excepción en cualquier punto (incluida la evaluación del valor de retorno) Dispose se seguirá llamando también.

Si bien es cierto que puedes tomar la ruta más larga, son dos líneas adicionales que solo añaden cruces y contexto adicional para realizar un seguimiento de (mentalmente). De hecho, realmente no necesita la variable local adicional, aunque puede ser útil en términos de depuración. Podrías tener:

public static Transaction GetMostRecentTransaction(int singleId)
{
using (var db = new DataClasses1DataContext())
{
return (from t in db.Transactions
orderby t.WhenCreated descending
where t.Id == singleId
select t).SingleOrDefault();
}
}

De hecho, incluso podría sentir la tentación de usar notación de puntos, y poner la condición Where en SingleOrDefault :

public static Transaction GetMostRecentTransaction(int singleId)
{
using (var db = new DataClasses1DataContext())
{
return db.Transactions.OrderByDescending(t => t.WhenCreated)
.SingleOrDefault(t => t.Id == singleId);
}
}

Answer 5

Sí, puede haber un efecto secundario. Por ejemplo, si utiliza la misma técnica en el método de acción ASP.NET MVC, obtendrá el siguiente error: "La instancia de ObjectContext se ha eliminado y ya no se puede usar para operaciones que requieren una conexión"

public ActionResult GetMostRecentTransaction(int singleId)
{
using (var db = new DataClasses1DataContext())
{
var transaction = (from t in db.Transactions
orderby t.WhenCreated descending
where t.Id == singleId
select t).SingleOrDefault();
return PartialView("_transactionPartial", transaction);
}
}