尽管脱离了 .NET Core 发布循环，但是 EF Core 正在开发其 3.0 路线图。除此之外，还对原来的 Entity Framework 进行了一些重要的变更。

更多服务器端的查询

将 LINQ 查询转换为对应的 SQL 查询通常是比较困难的，甚至是不可能的。许多 QRM 只能在转换失败时抛出一个运行时异常来解决这个问题，但是 EF Core 做了更多的尝试。当不能完全理解 LINQ 查询时，它会将其部分转换为 SQL，之后在客户端执行剩下的操作。尽管这可能会导致性能不好，很多开发人员更喜欢这种方案，而不是查询直接失败。

Diego B Vega写道，

在 EF Core 3.0 中，我们计划对 LINQ 实施和测试的方法进行重大变更。目标是让它变得更加健壮（比如说，避免在补丁发布版本中破坏查询），让更多表达式准确转换为 SQL，在更多情况下生成有效的查询，防止没有检测到效率低下的查询的情况发生。

C# 8.0 支持

EF Core 3.0 将成为第一个支持 C# 8 的版本。这主要代表着 API 在更新之后可以包含 [可为空的引用类型] 和异步流。关于如何做到这一点仍待确定，因为 EF Core 3.0 的一大目标是保留 .NET Standard 2.0 库。这可能会与 C# 8 的一些功能背道而驰。

因为 .NET Framework 不会支持 C# 8 的所有新功能，所以 Entity Framework 6.3 也不太见得可以支持 C# 8。

多对多关系

要在 EF Core 中表示多对多关系，目前你需要能表示映射表的“连接实体”。有了“属性包实体”功能之后，EF Core 离摆脱这种需求又更近了一步。

该特性支持实体将数据存储在索引属性中，而不是常规属性中，并且能够使用相同. NET 类的实例 (可能简单到 Dictionary<string, object>) 来表示相同 EF 核心模型中的不同实体类型。

请注意，Entity Framework 已经在不需要连接实体的情况下支持多对多关系。

存储过程

EF Core 3.0 timeframe 中不会提供对存储过程的一流支持。可以使用查询类型和原始 SQL 的变通方案。

Visual Studio Designer

Diego B Vega 写道：

我们了解设计可能是我们的一些客户使用 EF Core 的一个重要功能，但我们并没有看到很多反馈表示它比我们待办事项中的其他功能更加重要。我们很有兴趣了解你是否尝试代码优先开发，了解你是否知道有工具可以将现有的数据库反向工程到 EF Core 模型。

GraphQL

实现 GraphQL 是非常困难的。这个查询语言非常复杂，如果没有框架或者库来支持它，甚至是部分实现也很难做到。

几年以前 Microsoft 确实曾推出过使用 EF Core 的 GraphQL，但从来没有公开发布过。尽管还有很多 GraphQL 的设计问题需要得到解决，但他们还是希望能在未来真正实现这一功能。

原文地址:https://www.infoq.cn/article/yrNemH-ijJCIIdjMl4ep

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com