Saltar al contenido

Pasar parámetros de salida al procedimiento almacenado usando dapper en el código C#

este problema se puede resolver de variadas formas, pero te mostramos la que en nuestra opinión es la solución más completa.

Solución:

Con solo buscar en el archivo Test.cs, podría encontrar este ejemplo

    public void TestProcSupport()
    
        var p = new DynamicParameters();
        p.Add("a", 11);
        p.Add("b", dbType: DbType.Int32, direction: ParameterDirection.Output);
        p.Add("c", dbType: DbType.Int32, direction: ParameterDirection.ReturnValue);
        connection.Execute(@"create proc #TestProc 
                         @a int,
                             @b int output
                             as 
                             begin
                                 set @b = 999
                                 select 1111
                                 return @a
                             end");
        connection.Query("#TestProc", p, commandType: CommandType.StoredProcedure).First().IsEqualTo(1111);
        p.Get("c").IsEqualTo(11);
        p.Get("b").IsEqualTo(999);
    

Entonces, supongo que su código C# podría escribirse como

    public void InsertData()
    
        var p = new DynamicParameters();
        p.Add("VAR1", "John");
        p.Add("VAR2", "McEnroe");
        p.Add("BASEID", 1);
        p.Add("NEWID", dbType: DbType.Int32, direction: ParameterDirection.Output);
        connection.Query("SP_MYTESTpROC", p, commandType: CommandType.StoredProcedure);
        int newID =  p.Get("NEWID");
    

Como nota al margen, no utilice SP como prefix para su procedimiento almacenado. Está reservado para procedimientos definidos por el sistema y podría tener problemas si Microsoft decide usar el mismo nombre. Aunque improbable es una mala práctica y ¿por qué arriesgarse?

Además de la sugerencia de “ath”: para evitar la reflexión, DynamicParmers.AddDynamicParams() toma un objeto anónimo, después de lo cual puede agregar el parámetro de retorno como este …

var param = new  A="a", B="b" ;
var dynamicParameters = new DynamicParameters();
dynamicParameters.AddDynamicParams(parameters);
dynamicParameters.Add("return", dbType: DbType.Int32, direction: ParameterDirection.ReturnValue);

ahora use el objeto dynamicParameters en su elegante llamada en lugar del objeto param anónimo.

(También puede hacer esto para un parámetro de salida si lo prefiere)

Si siempre tiene un parámetro de SALIDA de tipo INTEGER llamado @id (@id = @id OUTPUT), podría crear un método de extensión como este que le permitiría usar el Dapper sintaxis pasando el sql string y un anonymous objeto:

using Dapper;
using System.Data;
using System.Data.SqlClient;

public static int ExecuteOutputParam
            (this IDbConnection conn, string sql, object args)
        
            // Stored procedures with output parameter require
            // dynamic params. This assumes the OUTPUT parameter in the
            // SQL is an INTEGER named @id.
            var p = new DynamicParameters();
            p.Add("id", dbType: DbType.Int32, direction: ParameterDirection.Output);

            var properties = args.GetType().GetProperties();
            foreach (var prop in properties)
            
                var key = prop.Name;
                var value = prop.GetValue(args);

                p.Add(key, value);
            

            conn.Execute(sql, p);

            int id = p.Get("id");
            return id;
        

Esto usa la reflexión para leer todas las propiedades, pero si puede tomar esa penalización, no tiene que repetir el DynamicParameters por cada llamada.

Para las transacciones, haga un método de extensión en SqlTransaction pasándolo a Execute así:

transaction.Connection.Execute(sql, p, transaction);

Recuerda que te permitimos valorar este post si diste con el arreglo.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *