实体框架核心继承创建子表

Question

public class Product
{
    public string Name { get; set; }
    public int Qty { get; set; }
    public decimal Price { get; set; }``
}
public class CartItem : Product
{
    public int CartItemId { get; set; }

    public string CartId { get; set; }
}
public class OrderLine : Product
{
    public int OrderLineId { get; set; }

    public int OrderId { get; set; }
}

public class Kititem : Product
{
    public int KititemId { get; set; }

    public int OrderId { get; set; }
}

public class SampleContext : DbContext
{
    public DbSet<CartItem> CartItems { get; set; }
    public DbSet<OrderLine> OrderLines { get; set; }
    public DbSet<Kititem> Kititems { get; set; }
}

如您所见，我没有在DbContext中包含父类Product，并且在进行迁移时，它将为每个派生类创建一个具有父类所有属性的表，并且它不会创建父类，因为没有包含在Dbcontext中，对我来说，这就是我正在探索并正在工作的东西，到目前为止，我对此感到满意。我的问题是这是否是一种不好的做法，也许我没有采用ef core继承的方式来处理所有问题？优点 ？我很困惑，想开始一个新项目并以最佳方式完成它，所以我不必再次重做

Answer 1

您使用的是“基类”，而不是“基实体”，即参与数据库模型继承的类。

您根本不会被迫使用数据库继承。此外，EF Core 目前仅支持Table per Hierarchy (TPH)策略，如果您有许多具有许多不同属性的派生实体（因为所有数据都存储在单个表中），这不是最好的。

换句话说，不使用数据库继承并没有错。数据库继承的唯一好处是如果您需要多态查询，即返回Product不同类型 s 的查询。可以使用Union/ ConcatLINQ 运算符在没有数据库继承的情况下执行此类查询，但由于当前 EF Core 缺乏将此类查询转换为 SQL，因此它们效率不高，因此它们始终使用客户端评估。

当然，这将在未来的某些 EF Core 版本中得到改进（以及对其他继承策略的支持），因此主要问题应该是 - 您是否需要这样的查询。如果不这样做，那么不使用数据库继承的方法就很好。如果你这样做了，那么决定哪一个更适合你的需要 - 手动Concat或包含很多列的单个表。