Entity Framework 6.3 和 EF Core 3.0 路线图

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

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

基于 .NET Core 3 的 Entity Framework 6.3

首先，Entity Framework 已经结束了。从功能方面，已经没有新的东西要加入到 Entity Framework 6.x 系列，而且不太可能出现 Entity Framework 7 了。

即便如此，Entity Framework 还没有被完全遗忘。Microsoft 已经认识到将遗留数据库代码从 EF 6 转移到 EF Core 并非一件易事，这也是采用 .NET Core 的一大障碍。

目前的计划是提供运行在 .NET Core 上的 Entity Framework 的旁支版本。这需要全新的特定于数据库的提供程序。另外，有些功能（比如 SQL Server 的空间数据）将不被支持。

本文中的其余内容适用于 EF Core。

更多服务器端的查询

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

Diego B Vega 写道，

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

NoSQL 支持

很长一段时间，人们都希望 ORM 可以无缝地处理 SQL 和 NoSQL 数据库。尽管 Microsoft 一开始宣布它将作为 EF Core 2.1 路线图的一部分，但是公司目前仍然在尝试引入这一功能。新的计划是在 EF Core 3.0 中提供对 Cosmo DB 的支持。

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。

更好地支持视图

不像 Entity Framework，EF Core 不能在数据库中为视图产生查询类型。查询类型仅适用于可以从数据库中读取但不能写入的实体。通常，这应该是查询视图、存储过程或表值函数的结果。

代码生成器的这一疏忽预期将在 EF Core 3.0 中修复。

多对多关系

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

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

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

不在 EF Core 3.0 路线图上的功能

由于预算有限，并不是所有的需求都能加入到路线图中来。以下这些特性虽然没有加入其中，但也很有必要提一下。

存储过程

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

每个类型继承的表

当表很宽，有很多列的时候，一项解决此问题的技术是每个类型继承的表（Table Per Type inheritance）。使用该模型之后，每行都会被识别为多个子类型之一。每个子类型都有自己的表，表中有这个子类型特有的列。只有所有子类型都有的列才会保留在原始表中。

目前 Entity Framework 支持每个类型继承的表这一功能，但是 EF Core 并不支持。尽管从 2015 年开始，大家都非常希望这个功能可以实现，但它也是很有争议的。对于有些人来说会将它视为反模式，因为如果不恰当使用，它就会损伤性能。

另外一些人认为每个类型继承的表可以提升性能，因为连接原始和子类型表的成本会比处理一个很宽的表来的小。另外，现实世界的数据库已经使用了这种模式，EF Core 需要和这些现有的数据库保持一致。

还有，EF Core 中不需要每个类型继承的表，是因为 Entity Framework 中已经存在了，而且 EF 计划会移植到 .NET Core 中来。人们对此的反驳是，我们可能既需要每个类型继承的表，也需要 EF-Core 独有的功能。

Visual Studio Designer

Diego B Vega 写道：

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

更新插入

更新插入是有条件地插入或更新一条记录的功能，这被视为 ORM 的第二层功能。尽管没有必要，但拥有它也是很好的，因为它可以减少往返访问数据库的次数，并简化代码。然而，它目前并不适合 EF Core 模型。部分原因是它实现的方式在各个数据库之间存在太大的差异。有些具备明确但独特的语法。有些利用 MERGE 语句，但由于它不是原子性可能会产生问题。还有 Jet/MS-Access 完全不接受更新插入，但是可以用多个查询来模拟。

更新插入目前在 Github 上的 Merge/Upsert/AddOrUpdate 支持思路中讨论。

GraphQL

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

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

查看英文原文： Entity Framework 6.3 and EF Core 3.0 Roadmap