Question

考虑以下场景（在代码优先工作流程中使用带有VS 2017的EF6）。

我有一个基本的抽象实体库类（它提供了一个ID属性和一些适用于所有实体的其他属性）。

我有一个继承实体库的联系人类。它也是抽象的，并为应用程序将使用的典型业务对象（例如Customer和Supplier）提供公共属性，并提供诸如First和Last Name之类的东西。

最后，还有从Contact继承的单独的Customer和Supplier类。

如果我将所有这些组件放在一个项目中，添加EF Nuget包，启用迁移，然后添加迁移我得到了我期望的每种类型表结构表（一个Contact表和单独的Customer和Supplier表）通过外键链接到联系人表）。联系人既可以是客户也可以是供应商的业务规则得到满足。

现在，在大规模应用程序中，公共基类很可能位于包含许多不同上下文共有项的单独项目中。联系人，客户和供应商类可能位于其自己的单独项目中，而联系人上下文则位于其自己的单独项目中。

如果我复制该场景，然后启用并添加迁移，我最终会将单独的Customer和Supplier类与他们从Contact继承的字段的副本结束，但没有Contacts表。业务规则立即被打破。

这是EF6的已知问题吗？

如果这是一个小型应用程序，我只需将所有内容捆绑到一个项目中（所有这些都分成各种文件夹）但是我希望沿着代码第一行重新构建现有的更大的应用程序，并将各种模式分开分成几个部分，它们本身很可能由许多项目组成，更有意义。我可能做错了，因为我还是先开始使用代码，但如果有人遇到这个问题，我会欢迎任何想法，或者我知道我应该如何安排组件来使其工作。

Answer 1

在这种情况下，EF6基本实体发现过程似乎存在问题（当实体类程序集与DbContext程序集不同时）。

根据经验，始终公开继承根实体的多态DbSet，或使用Entity<T>()流畅的API明确标识它。

因此，以下两个选项中的任何一个都可以解决问题：

public class MyDbContext : DbContext
{
    // ...
    public DbSet<Contact> Contacts { get; set; }
    // ...
}

或

public class MyDbContext : DbContext
{
    // ...
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        // ...
        modelBuilder.Entity<Contact>();
        // ...
    }
    // ...
}

在解决方案中的多个项目中创建TPT继承时，EF6.x是否存在问题？

1 个答案: