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)策略，如果您有许多具有许多不同属性的派生实体（因为所有数据都存储在一个表中），这并不是最佳选择。

换句话说，不使用数据库继承没有任何错误。数据库继承的唯一好处是，如果您需要 polymorphic 查询，即返回不同类型Product的查询。可以使用Union / Concat LINQ运算符在不进行数据库继承的情况下进行此类查询，但是由于当前的EF Core缺少将此类查询转换为SQL的原因，它们的效率较低。 client evaluation。

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

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

1 个答案: