EF Core、OData v4、Automapper - 使用嵌套 $expand 查询时出现空引用异常答案

【问题标题】：EF Core, OData v4, Automapper - Null reference exception when querying with nested $expandEF Core、OData v4、Automapper - 使用嵌套 $expand 查询时出现空引用异常
【发布时间】：2018-08-13 13:22:04
【问题描述】：

我遇到了一个奇怪的问题，我一直在努力解决几天。

我有一个项目，我在其中使用 OData 访问实体集，这些实体集是由 Automapper 从实体框架实体映射的 DTO。这一切都在一个 ASP.NET Core Web API 项目上。

我有一个导致问题的特定设置。

具有 1:1 子级的实体，其本身具有 1:1 子级，两种关系都是可选的。
我正在查询的实体集存在，但与其他两个实体集的关系为空。
我用 OData 的/api/Foos$expand=man($expand=chu) 查询。
这会导致空引用异常。

ASP.NET Core Web 服务器的完整输出位于此处 - https://gist.github.com/nickspiers/3620840145d0a88e3966643613a5d442

以最简单的形式重现该问题 - https://github.com/nickspiers/efcore-issue

我试图将所有内容归结为最简单的部分，但如果我忘记了更多信息，请告诉我我还能提供什么。谢谢！

【问题讨论】：

如果有人对解决方法感兴趣：stackoverflow.com/a/64177122/6297069 但如果有真正的解决方案，请分享

标签： c# odata automapper asp.net-core-webapi ef-core-2.1

【解决方案1】：

是的，现在前往 Odata 和 Entity Framework Core github 站点并感到震惊。

遗憾的是，您无能为力。错误的 TOMS - EF Core 在某些情况下几乎不可用。

官方立场是，这一切都可能在 3.0 时间范围内得到解决 - 您可能可以在 2019 年夏季使用。不是开玩笑。在此之前，他们遇到的所有 LINQ 问题都被推迟了。2.1 - 不重要。 2.2 - 小版本，不是硬 linq 工作。祝您等待愉快。

这里是同一个地方。

我在这里开启了一个讨论：

https://github.com/aspnet/EntityFrameworkCore/issues/12953

答案包括：

查询缺少测试覆盖率。我们正在研究这方面的一些前线，但它的工作量并不小，而且会占用资源从添加功能或修复错误 - 一个原因 2.2 更小发布。其中一部分将使人们更容易提交测试。

和

很明显，使用 OData 会导致某些查询模式比编写查询时更常见用手。这使得它特别容易缺乏测试覆盖率。

OData WebApi 也有一个未解决的问题。

目前唯一合理的解决方法可能是：

将项目类型更改为 net472
使用 Asp.net 等。不在 dotnet 核心中
这允许您使用现代 asp.net 但实体框架。

6.2 可能过时了，可能“没有所有的花里胡哨” - 但它在 LINQ 方面的错误要少得多，并且实际上可以在这种情况下使用。

这不是 OData 问题的核心 - LINQ 是有效的。这完全是一个 EF Core 产品问题，在翻译/提供者网站上发布时出现了明显的问题，这些问题都没有得到任何优先处理，但似乎积压了 3.0

现在，在您的特定情况下 - 您执行 ProjectTo，对吗？你把包括在那里？ Ef Core 有其他问题。是的，不是开玩笑。但是公共中有代码可以提取所需的包含，您可以使用它。您肯定需要提取包含然后在 ProjectTo 中使用它们。

我使用它和第二部分（检查是否存在某些构造）检查我是直接返回 IQUEeryable 还是先执行 ToList（这会导致内存处理效率低下，但有些事情需要它）。

编辑：

从 .Net 5 开始，许多自动映射器问题都得到了改进，并且提供了一个新的扩展包 AutoMapper.Extensions.OData，它带来了测试改进、.Net api 控制器抽象类和属性，例如 ODataController 和 [EnableQuery]。详情请见https://github.com/AutoMapper/AutoMapper.Extensions.OData。

【讨论】：

我确实使用 ProjectTo，添加包含似乎没有帮助。我目前正在使用 ToList 作为一种解决方法，但就像你说的那样 - 效率很低。如果没有人回答其他问题，我可能会像您建议的那样考虑切换到 EF 6.2，直到核心版本更加成熟和稳定。
如果有人回答更好，我很乐意实施。我喜欢 Odata，但当前的堆栈被每个级别上的大量错误所困扰。 EF Core 处于中间位置，可能对 75% 的问题负责。
我理解您的痛苦 - 幸运的是，我只是从外部监视 EF Core（不在生产中使用它）。知道 OData 查询在 EF 查询之上添加了什么会很有趣，因为纯 ProjectTo + ToLIst() 在 2.1.1 中工作得很好
没什么。这与添加无关 - Odata 基本上公开了查询语法，因此您可以通过 URL 以工具支持的标准方式进行过滤和包含。这被传输到标准 linq 中。如果您删除 ToList，那么您会得到....嘿，性能。哪个 ToList 没有。我们中的一些人在大数据上运行它 - 如果您可以使用来自 odata 的查询在 sql 级别过滤一百万个条目并避免 ToList...嘿，性能。
我明白这一点。这个问题更多是出于好奇，在ProjectTo（基本上是Select）EF 查询之上的 LINQ 构造使 EF Core 查询翻译器和/或处理器感到困惑。但无论如何，我发现我自己 - 当在它上面应用二次投影时，条件对象投影会以某种方式中断。是的，EFC 查询部分远非应有的（或曾经在 EF6 中的）。我喜欢 EFC 生成的查询的优雅，但是当它们不起作用时，它真的没关系。太糟糕了，他们专注于其他事情。