Consultar procedimientos almacenados con .NET Core

Para que tu aplicación realizada en .NET Core pueda ejecutar un procedimiento almacenado de una base de datos Microsoft SQL Server podemos usar dos métodos: Entity Framework o ADO.

Para poder verificar el funcionamiento de ambos métodos he creado una pequeña aplicación que nos permite además conocer el tiempo medio de ejecución de cada uno de ellos.

Para agilizar un poco vamos a obviar la estructura del modelo usado, centrándonos exclusivamente en el código usado para poder obtener la información de la base de datos.


Con Entity Framework:


Como siempre, una pasada, tiras dos líneas de código y ya tienes tu objeto con la información devuelta por el procedimiento. Nada que ver con ADO.

El código sería tal que así:


// declaramos nuestra clase contexto de la BD
private readonly ContextoBD _contexto;

[HttpGet("servicioscontratados/{idCliente}")]
public async Task GetConEF(int idCliente)
{       

      var parametro = new SqlParameter("@vIdCliente", idCliente);
     return await _contexto.Servicio.FromSql("pa_Servicios @vIdCliente", parametro).ToListAsync();

}


Solo debemos crear un parámetro sql que pasaremos al método FromSql de nuestro contexto de base de datos una vez especificado el modelo con el que deseamos trabajar, en este caso con Servicio.... y chimpún, ya lo tienes.


Con ADO:

Con ADO debemos usar bastante más código. Si llevas tiempo trabajando con .NET Framework sabes de lo que hablo. Tendremos que crear una conexión, un objeto Command y trabajar un poco más la asignación de la información para poblar nuestro modelo.

El código sería el siguiente: 


[HttpGet("servicioscontratadosADO/{idCliente}")]
public async Task GetConADO(int idCliente)
{
           

using (SqlConnection bdSql = new SqlConnection(_cadenaConexion))

       {

        using (SqlCommand bdComando =  new SqlCommand("pa_Servicios", bdSql))

             {

              bdComando.CommandType = CommandType.StoredProcedure;
               bdComando.Parameters.Add(new SqlParameter("@vIdCliente", idCliente));
               var servicios = new List();
               await bdSql.OpenAsync();

             using (var recordset = await bdComando.ExecuteReaderAsync())
             {
                   while (await recordset.ReadAsync())
                   {
                   // asignamos los valores del recordset mediante un 
                   // método en el que formateamos los valores recibidos
                   servicios.Add(RecordsetServicios(recordset));
                   }
             }

             return servicios;

             }

        }            

}


Como puedes ver el código es bastante más extenso que el necesario para conseguir el mismo resultado con Entity Framework. Debemos crear la conexión, el sqlCommand para obtener la información y asignar al objeto servicios los valores recogidos con el recordset manualmente. Esta asignación, si lo recuerdas, usando Entity Framework se realiza de manera automática y en una sola línea de código.


Conclusiones

En definitiva, las dos opciones son válidas, funcionan perfectamente y devuelven el mismo resultado. Solo queda hacer una prueba: obtener el tiempo de ejecución de cada opción.

Para obtener el tiempo de ejecución he usado la clase Stopwatch, clase muy utilizada para estos menesteres.

Para hacer funcionar a Stopwatch solo debemos implementar estas líneas de código:


Stopwatch tiempo = new Stopwatch();
        tiempo.Start();

        // codigo ADO o Entity Framework


        tiempo.Stop();
        return ("Tiempo usado: " + tiempo.Elapsed.ToString("hh\\:mm\\:ss\\.fff"));


Pues una vez ejecutadas las dos posibilidades me devuelve unos tiempos muy aclaradores. Unos 600 milisegundos para la consulta con EF y solo 150 milisegundos para la consulta con ADO. ¡Vaya diferencia de tiempos! 

Según he leído varios desarrolladores recomiendan directamente el uso de ADO. Desde luego, por tiempos parece que es la mejor opción.

No se qué pensarás tú. Pero si quieres, puedes dejarme tu comentario. Seguimos!