El día de hoy aprendí un tip bastante bueno de como usar
using gracias a
Eber Irigoyen.
Todo comenzó porque él hizo un comentario en el
último artículo recalcando la importancia de usar
using para TODOS los objetos relacionados con la base de datos (conexiones, comandos, transacciones, etcétera). A mí se me hacía un poco de
overkill, pero ahora comprendo que en realidad sí es un buen consejo.
Por si no sabes ni de qué hablo, esta instrucción define un alcance (
scope) explícito para un objeto, fuera del cual el objeto es automáticamente "dispuesto" (manda llamar su método
Close() o
Dispose()), incluso si se levanta una excepción dentro de ese bloque.
Aunque estrictamente hablando no es necesario, ya que hay un scope implícito cada vez que abres y cierras llavecitas en C#, para recursos limitados como conexiones de red, el scope explícito que crea el
using ayuda a que el garbage collector reclame esos recursos más fácil y rápidamente.
Si no lo tuvieras,
tendrías que hacer todo a punta de bloques
try/
catch/
finally. Eso era algo que no me gustaba de VB 7--bueno VB .NET o "VB 2003", como le quieran llamar. Afortunadamente VB 8 (2005) ya lo trae.
En el artículo original no la quise complicar mucho con esto, pero así quedaría el "patrón de uso de un DataReader" usando
try/
catch/
finally:
string miStringDeConexion =
@"Data Source=.\SQLEXPRESS;Initial Catalog=AdoNetDemo;" +
"Integrated Security=True";
string miQuery = "SELECT * FROM Peliculas;";
SqlDataReader speedy = null;
SqlConnection miConexion = null;
SqlCommand miCommando = null;
try
{ // en cualquiera de las instrucciones de este bloque se podría
// levantar una excepción
miConexion = new SqlConnection(miStringDeConexion);
miCommando = new SqlCommand(miQuery, miConexion);
miConexion.Open();
speedy = miCommando.ExecuteReader();
while (speedy.Read())
{ // hacer mi desmater
}
}
catch (SqlException)
{ // hacer algo para intentar recuperarme o re-lanzar exception
// si no pienso hacer nada, es mejor omitir el catch
}
catch
{ // hacer algo para intentar recuperarme o re-lanzar exception
// si no pienso hacer nada, es mejor omitir el catch
}
finally
{ // haya o no haya ocurrido excepción, siempre debemos asegurarnos
// de cerrar las conexiones, DataReaders, etc.
if (!speedy.IsClosed)
speedy.Close();
if (miConexion != null)
miConexion.Close();
if (miCommando != null)
miCommando.Dispose();
}
Como puedes ver, es medio engorroso. Por eso el
using es tan cool.
Pero, yo tenía mis reservas, porque cuando tienes varios objetos, es fácil--pensaba yo--que acabes con un chorro de
usings anidados, lo cual no me gustaba:
// asumiendo que TipoA, TipoB y TipoC son clases que
// implementan IDisposable
using (TipoA a = new TipoA())
{ using (TipoB b = new TipoB())
{ using (TipoC c = new TipoC())
{ // hacer mi desmater
} // using dispone c
} // using dispone b
} // using dispone a
Ahora, también sabía que
using soporta declarar varios objetos
del mismo tipo dentro del paréntesis. Algo así como esto:
// De nuevo, asumiendo que TipoA implementa IDisposable
using (TipoA a1 = new TipoA(), a2 = new TipoA(), a3 = new TipoA())
{ // hacer mi desmater
} // using dispone a1, a2 y a3
Lo cual no es muy útil cuando tienes objetos de
distintos tipos, como en el patrón de uso de un DataReader--donde tienes que usar SqlCommand, SqlConnection y SqlDataReader.
Así que por eso se me hizo tan chido cuando Eber me comentó que
using soporta una sintaxis más o menos así:
// asumiendo que TipoA, TipoB y TipoC son clases que
// implementan IDisposable
using (TipoA a = new TipoA())
using (TipoB b = new TipoB())
using (TipoC c = new TipoC())
{ // hacer mi desmater
} // using dispone a, b y c
De esa forma podría re-escribir el ejemplo de esta forma:
string miStringDeConexion =
@"Data Source=.\SQLEXPRESS;Initial Catalog=AdoNetDemo;" +
"Integrated Security=True";
string miQuery = "SELECT * FROM Peliculas;";
using(SqlConnection miConexion = new SqlConnection(miStringDeConexion))
using(SqlCommand miCommando = new SqlCommand(miQuery, miConexion))
{ miConexion.Open();
using (SqlDataReader speedy = miCommando.ExecuteReader())
{ while (speedy.Read())
{ // hacer mi desmater }
} // using manda llamar speedy.Close()
} // using manda llamar miConexion.Close() y miComando.Dispose()
Ahora, nomás de payaso modifiqué un poco el código para verificar que en realidad se estuvieran mandando llamar los
Dispose(), agregando manejadores para el evento
Disposed tanto de la conexión como del comando de la siguiente forma:
public static void UsandoUsing() {
string miStringDeConexion =
@"Data Source=.\SQLEXPRESS;Initial Catalog=AdoNetDemo;" +
"Integrated Security=True";
string miQuery = "SELECT * FROM Peliculas;";
using(SqlConnection miConexion = new SqlConnection(miStringDeConexion))
using(SqlCommand miCommando = new SqlCommand(miQuery, miConexion))
{ miConexion.Disposed += new EventHandler(miConexion_Disposed);
miCommando.Disposed += new EventHandler(miCommando_Disposed);
miConexion.Open();
using (SqlDataReader speedy = miCommando.ExecuteReader())
{ while (speedy.Read())
{ // hacer mi desmater }
} // using manda llamar speedy.Close()
} // using manda llamar miConexion.Close() y miComando.Dispose()
}
static void miConexion_Disposed(object sender, EventArgs e)
{ Console.WriteLine("miConexion liberada"); }
static void miCommando_Disposed(object sender, EventArgs e)
{ Console.WriteLine("miComando liberado"); }
¿El resultado?
Oh yeah.