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

问题描述：

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; }
}

如您所见，我没有将父类Product包含在其中DbContext，并且在进行迁移时，它将为每个派生类创建一个具有父类所有属性的表，并且不会创建父类，因为Dbcontext中不包含该类，对我而言，这就是我要保护的对象，是有效的，到目前为止，我对此感到满意。
Mi问题是这是否是一种不好的做法，也许我没有以可以利用所有优势的方式使用ef core继承？
我很困惑，想开始一个新项目并以最佳方式完成它，所以我不必再次重做

As you can see in this I am not including the parent class Product in the DbContext, and when doing the migrations it creates a table for each derived class with all the properties form the parent class, and it does not create the parent class because is not included in the Dbcontext, for me it was what I was exptecting and is working, and I am happy with it so far Mi question is if that is a bad practice and maybe I am not using ef core Inheritance the way I can take all the advantages ? I am confuse and want to start a new project and do it the best way, so I don't have to redo it again

答

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

What you are using is called "base class" as opposed to "base entity", i.e. class participating in database model inheritance.

您不是完全*使用数据库继承。此外，EF Core当前仅支持每个层次结构表（TPH）策略，如果您有许多具有许多不同属性的派生实体（因为所有数据都存储在一个表中），那不是最好的选择。

You are not forced to use database inheritance at all. Moreover EF Core currently supports only Table per Hierarchy (TPH) strategy, which is not the best if you have many derived entities with many different properties (because all the data is stored in a single table).

不使用数据库继承没有错。数据库继承的唯一好处是是否需要 polymorphic 查询，即返回不同类型的 Product s的查询。可以使用 Union / Concat LINQ运算符进行不带数据库继承的查询，但不会由于当前的EF Core缺乏将此类查询转换为SQL的效率很高，因此它们始终使用客户评估。

In other words, there is nothing wrong to not use database inheritance. The only benefit of database inheritance is if you need polymorphic queries, i.e. queries that return Products of different types. It's possible to do such queries w/o database inheritance using Union / Concat LINQ operator, but they won't be efficient due to current EF Core lack of translating such queries to SQL, so they always use client evaluation.

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

Of course this will be improved in some future EF Core version (as well as support for other inheritance strategies), so the main question should be - do you need such queries. If you don't, then your approach of not using database inheritance is just fine. If you do, then decide which is more suitable for your needs - manual Concat or a single table with a lot of columns.

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

相关推荐