我对此略有不同;在进行性能分析时(使用我们的 shiny profiler),我们注意到LINQ(在本例中为sql)正在为基本查询生成Tsql,并且操作在DB服务器上运行得非常快(0.5ms等) – 但实际上查询操作花费的时间更长(对于相同的0.5ms查询,在某些情况下为20ms).那么时间到了哪儿？您可能会想到“查询翻译”,但没有;我们还有很多ExecuteQuery< T>代码(即你手工编写Tsql的地方),这是完全相同的事情.事实证明,在物化者和身份地图之间的某个地方,大量的时间正在流失.

所以;我们编写了自己的物化器,它实际上是ExecuteQuery的替代品 – 因此诞生于dapper.

在更多的LINQ方面,它通常可以为简单查询生成Tsql,但对于任何复杂的东西,我通常更信任手工编码的Tsql.以案例为样本,我有一个涉及组,跳过和接受的复杂查询.它表现不佳.当我用ROW_NUMBER()等手写它时,相同的结果占了“统计IO”和总时间的4％.

我目前对LINQ的看法是,ORM工具使数据变异变得轻而易举,但对于查询,我倾向于使用dapper.这是具有讽刺意味的,因为LINQ中的Q是“查询”.