EF-Code zuerst - konfigurieren One-to-Zero-One-Beziehung ohne gemeinsame PK/FK

Question

Ich versuche, eine One-to-Zero-One-Beziehung zwischen zwei Entitäten einzurichten und ich möchte die abhängige Entität still eine eigene Spalte "Identity" enthalten, anstatt ein gemeinsamer Schlüssel zu sein.

Ich möchte so viel wie möglich zu tun, die Konventionen folgen und nicht ausdrücklich etwas zu erklären, die nicht explizite Deklaration erfordern (so, keine unnötigen Daten Anmerkungen oder fließend api Klauseln)

Das entites:

public class File 
{ 
    public int FileId {get;set;} 
    //some omitted file properties 
    public virtual Task Task {get;set;} 
} 

public class Task 
{ 
    public int TaskId {get;set;} 
    //some omitted task properties 
    public int FileId {get;set;} 
    public virtual File File {get;set;} 
} 

protected override void OnModelCreating(DbModelBuilder modelBuilder) 
     { 
      modelBuilder.Entity<File>().HasOptional(f => f.Task).WithRequired(t => t.File); 
      base.OnModelCreating(modelBuilder); 
     } 

Dies erstellt eine seltsame Beziehung, wobei die TaskId sowohl PK- als auch FK-Spalte der Tasks-Tabelle ist. Was, denke ich, sollte es den gleichen Wert wie die Datei-ID haben? (Das ist eine Frage :))

Also, wie mache ich TaskId einen eigenen, sequentiellen Wert und haben FileId ein Fremdschlüssel für die Tabelle Dateien geworden?

Oder vielleicht im Fall 1-0..1 sollte ich lieber die TaskId-Eigenschaft loswerden und FileId die PK/FK-Eigenschaft machen?

Prost!

Answer 1

Bidirektionale one-to-one Beziehung mit expliziten FK-Eigenschaft wird nicht unterstützt.

Also entweder weiter verwenden, was Sie jetzt haben - Shared Primary Key association. Entfernen Sie einfach eine der Eigenschaften TaskId oder FileId von Task und machen Sie den verbleibenden ein PK (EF wird automatisch als FK verwenden, da dies das Standard-Beziehungsmodell EF one-to-one ist).

Oder die FieldId Eigenschaft von Task loszuwerden und verwenden Sie die folgende fließend Konfiguration (alle sind erforderlich):

modelBuilder.Entity<File>() 
    .HasOptional(f => f.Task) 
    .WithRequired(t => t.File) 
    .Map(m => m.MapKey("FileId")) 
    .WillCascadeOnDelete(); 

Aber ich würde empfehlen, den ersten Ansatz (wenn es kein besonderer Grund von nicht zu tun ist es mag vorhandene Datenbank etc.), weil es besser unterstützt wird - das zweite schließt einige LEFT OUTER JOIN s in SQL-Abfragen ein, wie Sie von diesem Pfosten EF - WithOptional - Left Outer Join? sehen können.