Entity Framework 6.3 和EF Core 3.0路线图

短命女 2022-04-24 00:30 195阅读 0赞

尽管脱离了 .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\\u0026lt;string, object\\u0026gt;)来表示相同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