sql-server - 使用外键 (FK) 作为每层次结构表 (TPH) 的鉴别器

Question

[问:]是否可以在 EF 中使用 FK 作为判别器以及人们提出了哪些解决方法？

场景

EF 对象

public class List
{
    public int Id { get; set; }
    public string Name { get; set; }
    public ICollection<ListItem> Items { get; set; }
}

public abstract class ListItem
{
    public int Id { get; set; }
    public List List { get; set; }
    public string Text { get; set; }
}

数据库

不被 EF 独占使用(即无法更改)的现有数据库具有如下字段:

List
    Id         int not null      (identity)
    Name       varchar

ListItem
    Id         int not null      (identity)
    ListId     int not null      (FK to List.Id)
    Text       varchar

期望的结果

我希望列表的 ID 成为 ListItem 的鉴别器。即，对于列表中的每个条目，实现了一个从 ListItem 派生的单独类。

例如列表 [Id:1]

public class PersonListItem : ListItem
{
    public int PersonId { get; set; }
    public Person Person { get; set; }
}

public class ListItemConfiguration : EntityTypeConfiguration<ListItem>
{
    Map<PersonListItem>(m => m.Requires("ListId").HasValue(1));
}

在上述场景下，保存更改会导致 SQL 异常，因为 EF 在创建新的 ListItem 实例时尝试插入 List_Id。 List_Id 不是字段，我无法将 ListId 映射为 ListItem 上的属性，因为无法用作鉴别器。

到目前为止我的解决方案...

This Q&A解释了为什么他们决定不允许 FK 作为歧视者。

到目前为止，我的解决方法是向数据库添加另一个字段以用作鉴别器，然后使用插入触发器将其设置为与 ListId 相同的值(以处理非 EF 插入)并然后将 ListId 导航属性添加到 ListItem 实体。

有人有任何建议/替代方案吗？

Answer 1

最简单的解决方案在于引入一个枚举，用作表示类型的鉴别器。您提到的帖子清楚地描述了 FK 无法使用，因此您需要将其重构为可以应用的内容。它需要一些维护，但由于您还必须知道从列表项派生的类型，因此我不认为这是一个主要问题。您的其他选择是放弃 TPH 并使用 TablePerType。这样，您实际上不必引入枚举，但您将为每个派生列表项生成一个表。