2017-01-09 2 views
1

Ich muss Entity-Attribut-Value-Funktionalität für mehrere Datentabellen mit Entity Framework implementieren. Lassen Sie uns sagen, dass ich einen Attributwert EF Klasse, die wie folgt aussieht:Entity Framework-Fremdschlüssel für mehrere Tabellen/Entitäten

public class EntityAttributeValue 
{ 
    // Not important to my question. 
    public virtual Entity ParentEntity { get; set; } 
    public virtual EntityAttribute ParentEntityAttribute { get; set; } 

    // Field in question. 
    public Guid ParentSurrogateKey { get; set; } 

    public string Value { get; set; } 

    ... 
} 

Dann habe ich mehrere Entitäten, die mit ihnen ergänzende EAV Werte zugeordnet haben:

public class Entity1 
{ 
    // Key. EntityAttributeBalue.ParentSurrogateKey maps to this. 
    [Key] 
    public Guid SurrogateKey { get; set; } 

    // Standard properties. 
    public string Property1 { get; set; } 
    public string Property2 { get; set; } 

    // Collection of EAV values associated with this entity/table. 
    [ForeignKey("ParentSurrogateKey")] 
    public virtual IList<EntityAttributeValue> EntityAttributeValues { get; set; } 
} 

public class Entity2 
{ 
    // Key. EntityAttributeBalue.ParentSurrogateKey maps to this. 
    [Key] 
    public Guid SurrogateKey { get; set; } 

    // Standard properties. 
    public string OtherProperty1 { get; set; } 
    public string OtherProperty2 { get; set; } 

    // Collection of EAV values associated with this entity/table. 
    [ForeignKey("ParentSurrogateKey")] 
    public virtual IList<EntityAttributeValue> EntityAttributeValues { get; set; } 
} 

Mein Problem ist, dass beide ist Entity1 und Entity2 haben EntityAttributeValue Objekte mit ihnen assoziiert. Code first migrations versucht, einen Fremdschlüssel von EntityAttributeValue zurück zu Entity1 und einen anderen zurück zu Entity2 auf ParentSurrogateKey zu erstellen. Der Ersatzschlüssel für einen einzelnen gegebenen EntityAttributeValue ist nur entweder Entity1 oder Entity2 zugeordnet (oder expandiert eine EntityN ...), nicht beide/all.

Ich habe hier eine Beziehung viele zu viele, aber eine Seite nicht nur mehrere Zeilen, sondern mehrere Entitäten/Tabellen über eine gemeinsame GUID-Spalte zugeordnet.

Wie sollte ich mich dem nähern? Sollte ich nur die EntityAttributeValue-Fremdschlüssel zurück zu Entity1 und Entity2 von der automatischen Migration entfernen (was wäre ein langfristiger Schmerz)? Sollte ich die Liste der EntityAttributeValues ​​für eine bestimmte EAV-Entität manuell abrufen, statt mich auf EF zu verlassen, um das für mich zu tun?

+1

Ich denke, das war eine grundlegende EF-Newbie Frage. Wenn Sie es tatsächlich als number-to-many einrichten, werden die automatisch erstellten Join-Tabellen die Situation behandeln. Ich dachte, ich hätte es versucht, aber anscheinend nicht. Wenn dies erfolgreich verläuft, beantworte ich meine eigene Frage. –

Antwort

1

Nun, die Antwort erwies sich als offensichtlich und einfach. Ich musste eine Viele-zu-Viele-Beziehung mit FluentAPI definieren. In OnModelCreating, ich habe gerade hinzugefügt:

  modelBuilder.Entity<Entity1>() 
       .HasMany(m => m.EntityAttributeValues) 
       .WithMany(); 

      modelBuilder.Entity<Entity2>() 
       .HasMany(m => m.EntityAttributeValues) 
       .WithMany(); 

ich dachte ich, das versucht hatte, aber ich glaube, ich hatte nicht. Da die Viele-zu-Viele-Beziehung für jede Entität eine Zwischentabelle erstellt und sich die Fremdschlüssel in dieser Zwischentabelle befinden (und es nur eine Zeile in der Zwischentabelle gibt, wenn ein EntityAttributeValue für eine bestimmte Entität gilt), treten keine Fremdschlüsselprobleme auf .

+0

Ein Grund für meine Verwirrung war, dass es immer nur ein EntityN-Objekt für ein bestimmtes EntityAttributeValues-Objekt gibt. Da jedoch unterschiedliche EntityAttributeValues-Instanzen unterschiedlichen Typen (Klassen) von EntityN-Objekten zugeordnet werden können, ist die Darstellung der Beziehung "Viele zu Viele" ein Notbehelf, um Probleme zu vermeiden. Es gibt ein gewisses Potenzial dafür, dass diese Strategie vielleicht als "kludgy" betrachtet wird. –

Verwandte Themen