c# - 为什么 LET 语句的顺序在此 Entity Framework 查询中很重要？

Question

我正在处理的 Entity Framework 支持的 .NET Web 应用程序中的网格查询给出了 500 错误(转换为值类型“System.Int32”失败，因为物化值为 null。结果类型的通用参数或查询必须使用可空类型。)当网格行对象恰好在特定的一对多关系中具有零个子项时。 null 返回到一个不相关的整数属性。令人费解的是，颠倒 Linq 表达式中两个独立的 Let 语句的顺序使错误消失了。

也就是说，如果只有一个Widget(ID:1，CreatedOn:some datetime)，没有Bars和一个Foo(fValue:96)

from w in Widgets.OrderBy(w => w.CreatedOn)
let foo = w.Foos.FirstOrDefault()
let bar = w.Bars.FirstOrDefault()
select new { w.WidgetID, foo.fValue }

或

from w in Widgets
let bar = w.Bars.FirstOrDefault()
let foo = w.Foos.FirstOrDefault()
orderby w.CreatedOn
select new { w.WidgetID, foo.fValue }

按预期给出 {WidgetID: 1, fValue: 96}，但是

from w in Widgets.OrderBy(w => w.CreatedOn)
let bar = w.Bars.FirstOrDefault()
let foo = w.Foos.FirstOrDefault()
select new { w.WidgetID, foo.fValue }

返回 {WidgetID: 1, fValue: NULL} 这当然会崩溃，因为 Foo.fValue 是一个整数。

所有三个表达式在 Entity Framework 下生成略有不同的 SQL 查询，这是我所期望的 - 失败的表达式包含子句

... 
(SELECT TOP (1) 
    [Extent7].[fValue] AS [fValue]
    FROM   (SELECT TOP (1) [Extent6].[BarID] AS [BarID]
        FROM [dbo].[Bars] AS [Extent6]
        WHERE [Extent1].[WidgetID] = [Extent6].[bWidgetID] ) AS [Limit5]
    CROSS JOIN [dbo].[Foos] AS [Extent7]
    WHERE [Extent1].[WidgetID] = [Extent7].[fWidgetID]) AS [C1]
...

我认为这是罪魁祸首(0 个 Bars 与 1 个 Foo = 0 个结果交叉)。所以我理解错误的“方式”；让我困惑的是，我不知道为什么 LET 的顺序，或者我使用 Linq 方法调用的 OrderBy 与 Linq 表达式是否应该有所不同。

如果您想自己试验，这里是简化的表架构/数据:

create table Widgets (
    WidgetID int not null primary key,
    CreatedOn datetime not null
)    
insert Widgets values (1, '1995-02-03')

create table Foos (
    FooID int not null primary key,
    fWidgetID int not null references Widgets (WidgetID),
    fValue int not null
)
insert Foos values (7, 1, 96)

create table Bars (
    BarID int not null primary key,
    bWidgetID int not null references Widgets (WidgetID),
    bValue int not null
)

您能解释一下为什么这 3 个表达式在 Entity Framework 中逻辑上不等价吗？

Answer 1

我相信这是与已知 Entity Framework 问题相关的错误:https://entityframework.codeplex.com/workitem/1196 .根据问题，当使用 order by、let 和 FirstOrDefault 时，查询树被编译为错误的 SQL 查询。

遗憾的是，这个问题已经存在将近两年了，因此这个特定的错误对于 EF 团队来说可能不是一个高度优先的问题。也许它会在 EF7 中修复!