C#怎么使用Dapper执行存储过程_C#获取数据库Output输出参数【实战】-C#.Net教程-PHP中文网

Dapper调用带Output参数的存储过程必须使用DynamicParameters显式声明ParameterDirection.Output方向，确保参数名、dbType与存储过程定义严格一致，执行Execute()后通过Get("paramName")获取值。

c#怎么使用dapper执行存储过程_c#获取数据库output输出参数【实战】

怎么用 Dapper 调用带 Output 参数的 SQL Server 存储过程

Dapper 本身不封装 Output 参数的自动绑定逻辑，必须显式构造 DynamicParameters 并声明参数方向。直接传匿名对象或 new { } 会失败——Output 值根本不会被回写。

必须用 SqlMapper.IDynamicParameters 实现类，最常用的是 DynamicParameters（来自 Dapper NuGet 包）
声明 Output 参数时，dbType 必须与存储过程中定义的类型严格匹配（比如 DbType.Int32 对应 INT，不能用 DbType.Int64）
调用前不用给 Output 参数赋初值；调用后通过 param.Get("OutputParamName") 获取结果
如果存储过程有多个 Output/ReturnValue，每个都得单独 Add()，且 direction 设为 ParameterDirection.Output 或 ParameterDirection.ReturnValue

常见错误：执行后 Output 参数值仍是 null 或默认值

这几乎全是参数方向或类型不匹配导致的。Dapper 不报错，但 SQL Server 侧不会把值写回客户端参数。

忘了设 direction: ParameterDirection.Output —— 默认是 Input，Output 参数就变成只进不出
用错 dbType：比如存储过程里是 DECIMAL(18,2)，代码里传了 DbType.Decimal 却没指定精度，SQL Server 可能静默截断或拒绝赋值
参数名大小写不一致：SQL Server 默认不区分大小写，但某些连接字符串加了 Case Sensitive=True 就会失败
调用的是 Query() 却没处理返回结果集，而 Output 参数在结果集之后才生效；建议统一用 Execute() 或先取结果再读 Output

完整示例：调用带 Output 和 ReturnValue 的存储过程

假设 SQL Server 中有：

CREATE PROCEDURE [dbo].[usp_GetUserCountByStatus]
    @Status NVARCHAR(20),
    @Count INT OUTPUT
AS
BEGIN
    SELECT @Count = COUNT(*) FROM Users WHERE Status = @Status;
    RETURN ISNULL(@Count, 0);
END

C# 调用如下：

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

using Dapper;
using System.Data;
using System.Data.SqlClient;
<p>var conn = new SqlConnection(connectionString);
conn.Open();</p><p>var param = new DynamicParameters();
param.Add("@Status", "Active", DbType.AnsiString, ParameterDirection.Input);
param.Add("@Count", dbType: DbType.Int32, direction: ParameterDirection.Output);
param.Add("@ReturnCode", dbType: DbType.Int32, direction: ParameterDirection.ReturnValue);</p><p>conn.Execute("usp_GetUserCountByStatus", param, commandType: CommandType.StoredProcedure);</p><p>int outputCount = param.Get<int>("@Count");
int returnCode = param.Get<int>("@ReturnCode"); // 注意：这里是 Get<int>，不是 param["@ReturnCode"]</int></int></int></p>

为什么不用 SqlCommand 手动做？Dapper 这么麻烦值得吗

值得，但前提是项目已重度依赖 Dapper 且团队熟悉其扩展机制。纯手写 SqlCommand 确实更直白、调试更容易，但会丢失 Dapper 的管道复用、异步支持、自动映射等优势。

DynamicParameters 是线程不安全的，别跨请求复用同一个实例
如果存储过程返回多结果集（SET NOCOUNT OFF + 多个 SELECT），Output 参数仍有效，但要用 QueryMultiple() 配合 Read() 分步消费
Oracle/PostgreSQL 用户注意：DynamicParameters 对 Oracle 的 REF CURSOR 或 PG 的 REFCURSOR 输出不原生支持，得换 IDbCommand 底层方式

Output 参数的真实值，永远在 Execute() 或 Query() 完成之后才可读取——这是最容易漏掉的时机点。