Bueno, en realidad a mi no me parece que debiera ser tan desconocida. Sin embargo me encuentro continuamente con personas que no saben para que se usa o, más a menudo, que la confunden con el using de inclusión de un espacio de nombres que aparece en la parte de arriba de los archivos C#.
De hecho, una de las preguntas de test que hacemos a los candidatos para acceder a un puesto de programador en Krasis es precisamente: ¿Para qué vale la palabra clave 'using' tanto en C# como en VB? Y casi nadie la contesta bien, cosa que a mi me sorprende mucho. Lo que he subrayado en la pregunta anterior es lo que, en caso de duda, debería dar la pista ya que la sentencia de inclusión de espacios de nombres en VB es 'Imports', no 'using' como en C#, así que sólo queda la otra opción...
El objetivo de la cláusula using (en C#) o Using en VB es el de asegurar que los recursos asociados a un determinado objeto se liberan siempre, es decir, se emplea para asegurar que al acabar de usarlo siempre se llama al método Dispose() del objeto que referenciamos dentro de la declaración de using.
Traducido al cristiano veamos su utilidad en una situación muy común, por ejemplo, un acceso a base de datos.
Supongamos el siguiente código muy habitual (en C#, pero en VB sería casi idéntico):
using System.Data; //Este es el using de importación de espacio de nombres, que no es el que nos interesa
using System.Data.SqlClient;
SqlConnection conn = new SqlConnection();
try
{
//Aquí hacemos algo con la conexión
}
finally
{
conn.Close();
}
Es decir, abrimos una conexión, dentro del bloque try lanzamos una consulta o varias, etc.. El bloque finally se ha incluido para asegurarnos de que la conexión se cierra aunque se produzca un error en nuestro bloque de procesamiento, ya que de otro modo quedaría abierta y no se podría recuperar, disminuyendo la escalabilidad de nuestro programa. De hecho, el modo adecuado de hacer esto aún sería más complicado ya que la cláusula finally que he escrito da por hecho que la conexión está abierta y la cierra, pero si ya estuviese cerrada se produciría una excepción. Así que en un código real tendríamos que comprobar antes el estado de la conexión y luego llamar a Close(). En fin, una pesadez pero la única forma buena de hacerlo.... y de hecho me consta que muchos programadores ni siquiera lo tienen en cuenta. ¡Grave error!
Para evitarnos el tedio de escribir lo anterior pero aún así cerciorarnos de que la conexión se cierra podríamos emplear la cláusula using de la siguiente manera:
using System.Data; //Este es el using de importación de espacio de nombres, que no es el que nos interesa
using System.Data.SqlClient;
using(SqlConnection conn = new SqlConnection())
{
//Aquí hacemos algo con la conexión
}
Esto es equivalente a todo lo que comentaba en el párrafo anterior. Es decir, el 'using' se cerciora de que, al acabar el bloque de código entre sus llaves, aunque haya un error, se llama al método Dispose() del objeto conn que hemos declarado en su bloque inicial. Este método Dispose() es el que se cerciora de que los recursos de la conexión se liberen adecuadamente, incluyendo el cierre de la conexión.
Con using nos aseguramos de que nuestra aplicación no va dejando por ahí recursos mal liberados y el código queda mucho más compacto y fácil de leer, además de que no nos tenemos que preocupar de hacer la liberación de la manera adecuada ni de comprobar cosas como que una conexión está abierta antes de intentar cerrarla.
Por supuesto no tenemos porqué usarlo sólo para conexiones Cualquier objeto cuyos recursos debamos liberar es candidato a 'using', por ejemplo objetos de GDI+ (como pinceles, brochas y demás..), recursos de transacciones (los nuevos objetos TransactionScope de .NET 2.0), etc...
Aprendamos a sacarle provecho ya que su funcionalidad es fundamental para crear aplicaciones escalables y que hagan un uso racional de los recursos del sistema.
💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor
