返回一个结果集时，Dapper-dot-Net的“ Query”和“ QueryMultiple”在性能和行为上是否相等？

Question

我们最近构建了一个名为TableMapperT的映射类，该类封装了我们的Dapper多图功能。我们将其与名为TableCommand的“命令”对象分开构建，该对象包含sql文本信息等。为了使用它，我们必须使用“ QueryMultiple”，这对于返回单个结果然后映射它也是必需的。

我们已经运行了基本的性能指标，其性能似乎与常规的Query api相同（使用相同的多图对相同的查询进行循环，但是使用QueryMultiple使用“ Read（）”进行循环。

因此，问题是，对单个记录集使用QueryMultiple的性能或行为是否存在根本的劣势？似乎没有，但认为整个社区可能会有更深刻的见解。

Sam Saffron指出结果未在此帖子中进行缓冲（Dapper.NET和具有多个结果集的proc存储），但这是从前一阵子开始的，并且源代码看起来像“ buffered”现在为true（公共IEnumerable Read（bool缓冲= true）。

用法（下面）非常干净，它使我们可以在一个位置上纠缠连接和错误处理，这是对IDatabase对象的“查询”扩展方法。

var command = new TableCommand(<SQL>,<Parameters>,<Timeout>);
var mapper = new TableMapper<OrderLineItem>();  //return type here
mapper.SetMap<OrderLineItem,Product>((oli,p)=>{oli.Product = p;return oli}); //input types here

return this.Database.Query(command,mapper);//returns IEnumerable<OrderLineItem>

Answer 1

这里的问题不是性能，而是便利性。在我看来，大多数查询都是单一结果网格。更方便的是，不必处理多个网格读取器场景的额外复杂性，这必然更复杂，因为每个网格可以是不同的形状，并且只能以特定顺序读取它们。

关于缓冲：

• Read<T>/默认情况下Query<T>缓冲该网格，尽管可以将其关闭以实现完全流式传输
• 但是：多重网格 API 中的后续网格仅在收到请求时才被访问- 因此需要依次使用多重网格 API