Gibt es ein Problem mit EF6.x beim Erstellen TPT Vererbung über mehrere Projekte in einer Lösung?

Question

Betrachten Sie das folgende Szenario (mit EF6 mit VS 2017 in einem Code ersten Workflow).

Ich habe eine Basis abstrakte Entitybase-Klasse (die eine ID-Eigenschaft und ein paar andere Eigenschaften, die für alle Entitäten gelten würde) zur Verfügung stellt.

Ich habe eine Kontaktklasse, die Entitybase erbt. Es ist ebenfalls abstrakt und bietet allgemeine Eigenschaften für die typischen Geschäftsobjekte, die von der Anwendung verwendet werden (z. B. Kunde und Lieferant) und die Dinge wie Vor- und Nachname bereitstellt.

Schließlich gibt es die separaten Kunden- und Lieferantenklassen, die von Contact erben.

Wenn ich alle diese Komponenten in einem einzigen Projekt platziere, das EF Nuget-Paket hinzufüge, Migrationen aktiviere und dann eine Migration hinzufüge, erhalte ich die von mir erwartete Tabelle pro Typ-Tabellenstruktur (eine Kontakttabelle und einen separaten Kunden und Lieferanten) Tabellen, die durch einen Fremdschlüssel mit der Kontakttabelle verknüpft sind). Die Geschäftsregel, dass ein Kontakt sowohl ein Kunde als auch ein Lieferant sein kann, ist erfüllt.

Jetzt in einer großen Anwendung ist es sehr wahrscheinlich, dass die gemeinsame Basisklasse gut in einem separaten Projekt sein kann, das Elemente enthält, die in vielen verschiedenen Kontexten vorkommen. Die Kontakt-, Kunden- und Lieferantenklassen können sich gut in einem eigenen Projekt und dem Kontaktkontext in einem eigenen Projekt befinden.

Wenn ich dieses Szenario repliziere und anschließend Migrationen aktiviere und hinzufüge, habe ich separate Kunden- und Lieferantenklassen mit eigenen Kopien der Felder, die sie von Contact geerbt haben, aber keine Contacts-Tabelle. Sofort wurde die Geschäftsregel gebrochen.

Ist dies ein bekanntes Problem mit EF6?

Wenn dies für eine kleine Anwendung wäre, würde ich einfach alles in ein Projekt bündeln (alle in verschiedenen Ordnern getrennt), aber ich bin auf der Suche nach einer bestehenden viel größeren Anwendung entlang Code ersten Zeilen und brechen die verschiedenen Schemas umgestalten getrennt in einzelne Abschnitte, die selbst aus vielen Projekten bestehen können, macht mehr Sinn. Ich mag vielleicht etwas falsch machen, da ich immer noch mit dem Code anfange, aber ich würde mich über alle Gedanken freuen, wenn irgendjemand mir entweder begegnet ist oder weiß, wie ich vielleicht versuchen sollte, die Komponenten so einzurichten, dass sie funktionieren.

Answer 1

Es scheint ein Problem mit dem EF6-Basiseinheitsermittlungsprozess in diesem Szenario zu bestehen (wenn die Entitätsklassen-Assembly sich von der Assembly DbContext unterscheidet).

Als Faustregel gilt immer: Geben Sie eine polymorphe DbSet der Vererbungsstammeinheit ein, oder identifizieren Sie sie explizit mit der Entity<T>() fließenden API.

So eine der folgenden beiden Optionen wird das Problem lösen:

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

oder

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