【Entity Framework】聊一聊EF中继承关系

【Entity Framework】聊一聊EF中继承关系

一、概述

Entity Framework可以将.NET类型层次结构映射到数据库。这允许你像普通编程一样使用基类型和派生类型在代码中编写.NET实体，并让Entity Framework无缝创建适应的数据库架构，发出查询等。有关如何映射类型层次结构的实际细节取决于提供程序；本博文将介绍关系数据库上下文中的继承支持。

二、实体类型层次结构映射

按照约定，Entity Framework不会自动扫描基类型或派生类型；如果要映射层次结构中的CLR类型，就必须在模型上显式指定该类型。如，仅指定层次结构的基类型不会导致EF Core隐式包含其所有子类型。

示例将为Blog及其子类RssBlog公开DbSet。如果Blog有任何其他子类，它不会包含在模型中。

internal class MyContext : DbContext
{public DbSet<Blog> Blogs { get; set; }public DbSet<RssBlog> RssBlogs { get; set; }
}public class Blog
{public int BlogId { get; set; }public string Url { get; set; }
}public class RssBlog : Blog
{public string RssUrl { get; set; }
}

使用TPH映射时，数据库会根据需要自动设置为可为null。如，RssUrl列可为null，因为常规Blog实例没有该属性。

三、每个层次结构一张表和鉴别器配置

默认情况下，EF使用每个层次结构一张表（TPH）模式来映射继承。(TPH)使用单个表来存储层次结构中所有类型的数据，并使用鉴别器列来识别每行表示的类型。

上面的模型映射到以下数据库架构（注意隐式创建的Discriminiator列，它标识了每行中存储的Blog类型）。

	BlogId	Url	RssUrl
1	Blog	https://blog.csdn.net/songjianlong	NULL
2	RssBlog	https://blog.csdn.net/songjianlong

可以配置鉴别器列的名称和类型以及用于标识层次结构中每种类型的值：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{modelBuilder.Entity<Blog>().HasDiscriminator<string>("blog_type").HasValue<Blog>("blog_base").HasValue<RssBlog>("blog_rss");
}

在上面的示例中，EF在层次结构的基本实体上隐式添加了鉴别器作为影子属性。

protected overrid void OnModelCreating(ModelBuilder modelBuilder)
{modelBuilder.Entity<Blog>().Property("Discriminator").HasMaxLength(200);
}

最后，鉴别器也可以映射到实体中的常规.NET属性：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{modelBuilder.Entity<Blog>().HasDiscriminator(b => b.BlogType);modelBuilder.Entity<Blog>().Property(e => e.BlogType).HasMaxLength(200).HasColumnName("blog_type");modelBuilder.Entity<RssBlog>();
}

查询使用 TPH 模式的派生实体时，EF Core 会在查询中添加一个基于鉴别器列的谓词。 此筛选器确保对于结果中没有的基类型或同级类型，我们不会获得任何附加行。 对于基本实体类型，将跳过此筛选器谓词，因为查询基本实体将获得层次结构中所有实体的结果。 在具体化查询结果时，如果遇到未映射到模型中任何实体类型的鉴别器值，我们将引发异常，因为我们不知道如何具体化结果。 仅当数据库包含的行具有鉴别器值并且这些值未映射到 EF 模型时，才会发生此错误。 如果你有这样的数据，可以将 EF Core 模型中的鉴别器映射标记为不完整，以指示我们应始终添加筛选器谓词来查询层次结构中的任意类型。 IsComplete(false) 在鉴别器配置上调用会将映射标记为不完整。

protected override void OnModelCreating(ModelBuilder modelBuilder)
{modelBuilder.Entity<Blog>().HasDiscriminator().IsComplete(false);
}

四、共享列

默认情况下，当层次结构中的两个同级实体类型具有同名的属性时，它们将映射到两个单独的列。 但是，如果它们的类型相同，则可以映射到相同的数据库列：

public class MyContext : DbContext
{public DbSet<BlogBase> Blogs { get; set; }protected override void OnModelCreating(ModelBuilder modelBuilder){modelBuilder.Entity<Blog>().Property(b => b.Url).HasColumnName("Url");modelBuilder.Entity<RssBlog>().Property(b => b.Url).HasColumnName("Url");}
}
public abstract class BlogBase
{public int BlogId { get; set; }
}
public class Blog : BlogBase
{public string Url { get; set; }
}
public class RssBlog : BlogBase
{public string Url { get; set; }
}

使用强制转换查询共享列时，关系数据库提供程序（例如 SQL Server）不会自动使用鉴别器谓词。 查询 Url = (blog as RssBlog).Url 还将返回同级 Blog 行的 Url 值。 若要将查询限制为 RssBlog 实体，你需要在鉴别器上手动添加筛选器，例如 Url = blog is RssBlog ? (blog as RssBlog).Url : null。

五、每个类型一张表配置

在 TPT 映射模式中，所有类型都分别映射到各自的表。 仅属于某个基类型或派生类型的属性存储在映射到该类型的一个表中。 映射到派生类型的表还会存储外键来联接派生表与基表。

modelBuilder.Entity<Blog>().ToTable("Blogs");
modelBuilder.Entity<RssBlog>().ToTable("RssBlogs");

可以对每个根实体类型调用modelBuilder.Entity<Blog>().UseTptMappingStrategy()，而不是对每个实体类型调用ToTable,表名将由EF生成。

EF 将为上述模型创建以下数据库架构：

CREATE TABLE [Blogs] ([BlogId] int NOT NULL IDENTITY,[Url] nvarchar(max) NULL,CONSTRAINT [PK_Blogs] PRIMARY KEY ([BlogId])
);CREATE TABLE [RssBlogs] ([BlogId] int NOT NULL,[RssUrl] nvarchar(max) NULL,CONSTRAINT [PK_RssBlogs] PRIMARY KEY ([BlogId]),CONSTRAINT [FK_RssBlogs_Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [Blogs] ([BlogId]) ON DELETE NO ACTION);

如果重命名主键约束，新名词将应用于映射到层次结构的所有表。未来的EF版本将允许仅对特定表重命名约束。

六、每个具体类型一张表配置

在TPC映射模式中，所有类型都分别映射到各自的表。每张表都包含相应实体类型上所有属性的列。这解决了TPT策略的一些常见性能问题。

modelBuilder.Entity<Blog>().UseTpcMappingStrategy().ToTable("Blogs");
modelBuilder.Entity<RssBlog>().ToTable("RssBlogs");

无需对每个实体类型调用 ToTable，只需对每个根实体类型调用 modelBuilder.Entity<Blog>().UseTpcMappingStrategy() 即可按照约定生成表名。

七、TPC数据库架构

TPC策略类类似与TPT策略，除了为层次结构中每个具体类型创建不同的表，但表不是为抽象类型创建的，因此名称为“每个具体类型一张表”。与TPT一样，表本身指示已保存对象的类型。但是，与TPT映射不同，每个表都包含具体类型及其基类型中没个属性的列。TPC数据库架构是非规范化的

八、总结

TPH 通常适用于大多数应用程序，并且对于各种方案而言都是一个很好的默认值，因此，如果不需要 TPC，请不要添加 TPC 来增加复杂性。 具体而言，如果代码主要查询许多类型的实体，例如针对基类型编写查询，则倾向于使用 TPH，而不是 TPC。

尽管如此，当代码主要查询单个叶类型的实体并且你基准测试显示与 TPH 相比有所改进时，TPC 也是一种很好的映射策略。

仅当受外部因素约束时，才使用 TPT。