Eins-zu-viele-Beziehungen – EF Core (2023)

Eins-zu-viele-Beziehungen werden verwendet, wenn eine einzelne Entität mit einer beliebigen Anzahl anderer Entitäten verknüpft ist. Zum Beispiel einBlogkann viele verbunden habenBeiträge, aber jederPostist nur mit einem verbundenBlog.

Dieses Dokument ist anhand zahlreicher Beispiele aufgebaut. Die Beispiele beginnen mit häufigen Fällen, in denen auch Konzepte vorgestellt werden. Spätere Beispiele behandeln weniger häufige Konfigurationsarten. Ein guter Ansatz besteht darin, die ersten paar Beispiele und Konzepte zu verstehen und dann basierend auf Ihren spezifischen Anforderungen mit den späteren Beispielen fortzufahren. Basierend auf diesem Ansatz beginnen wir mit einfachen „erforderlichen“ und „optionalen“ Eins-zu-viele-Beziehungen.

Eins-zu-viele erforderlich

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft public Blog Blog { get; Satz; } = null!; // Erforderliche Referenznavigation zum Prinzipal}

Eine Eins-zu-Viele-Beziehung besteht aus:

• Ein oder mehrPrimär- oder AlternativschlüsselEigenschaften des Hauptunternehmens; das ist das „eine“ Ende der Beziehung. Zum Beispiel,Blog.ID.
• Ein oder mehrUnbekannter SchlüsselEigenschaften der abhängigen Entität; Das ist das „viele“ Ende der Beziehung. Zum Beispiel,Post.BlogId.
• Optional, aSammlungsnavigationauf der Hauptentität, die auf die abhängigen Entitäten verweist. Zum Beispiel,Blogeinträge.
• Optional, aReferenznavigationauf der abhängigen Entität, die auf die Hauptentität verweist. Zum Beispiel,Post.Blog.

Also für die Beziehung in diesem Beispiel:

• Die FremdschlüsseleigenschaftPost.BlogIdist nicht nullbar. Dies macht die Beziehung „erforderlich“, da jede abhängige (Post)muss mit einem Auftraggeber zusammenhängen(Blog), da seine Fremdschlüsseleigenschaft auf einen bestimmten Wert gesetzt werden muss.
• Beide Entitäten verfügen über Navigationen, die auf die entsprechende(n) Entität(en) auf der anderen Seite der Beziehung verweisen.

Diese Beziehung istdurch Konvention entdeckt. Das ist:

• Blogwird als Hauptperson in der Beziehung entdeckt undPostwird als abhängig entdeckt.
• Post.BlogIdwird als Fremdschlüssel des abhängigen Schlüssels entdeckt, der auf den verweistBlog.IDPrimärschlüssel des Prinzipals. Die Beziehung wird nach Bedarf ermittelt, weilPost.BlogIdist nicht nullbar.
• Blogeinträgewird als Sammlungsnavigation erkannt.
• Post.Blogwird als Referenznavigation erkannt.

Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasForeignKey(e => e.BlogId) .IsRequired( );}

Im obigen Beispiel beginnt die Konfiguration der Beziehungen mitHat vieleauf dem Hauptentitätstyp (Blog) und folgt dann mitMit einer. Wie bei allen Beziehungen ist es genau gleichbedeutend, mit dem abhängigen Entitätstyp zu beginnen (Post) und verwendenHabe einegefolgt vonMit vielen. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasOne(e => e.Blog) .WithMany(e => e.Posts) .HasForeignKey(e => e.BlogId) .IsRequired( );}

Keine dieser Optionen ist besser als die andere; beide ergeben genau die gleiche Konfiguration.

Optional eins-zu-viele

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int? BlogId { get; Satz; } // Optionale Fremdschlüsseleigenschaft public Blog? Blog { get; Satz; } // Optionale Referenznavigation zum Prinzipal}

Dies ist dasselbe wie im vorherigen Beispiel, außer dass die Fremdschlüsseleigenschaft und die Navigation zum Prinzipal jetzt nullbar sind. Dies macht die Beziehung „optional“, da eine abhängige (Post) kann existierenohnemit einem Auftraggeber verwandt sein (Blog).

Nach wie vor ist diese Beziehungdurch Konvention entdeckt. Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasForeignKey(e => e.BlogId) .IsRequired( FALSCH);}

Erforderlich Eins-zu-Viele mit Schatten-Fremdschlüssel

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } öffentlicher Blog Blog { get; Satz; } = null!; // Erforderliche Referenznavigation zum Prinzipal}

In manchen Fällen möchten Sie möglicherweise keine Fremdschlüsseleigenschaft in Ihrem Modell haben, da Fremdschlüssel ein Detail der Darstellung der Beziehung in der Datenbank sind, was nicht erforderlich ist, wenn die Beziehung rein objektorientiert verwendet wird. Wenn Entitäten jedoch serialisiert werden sollen, um sie beispielsweise über eine Leitung zu senden, können die Fremdschlüsselwerte eine nützliche Möglichkeit sein, die Beziehungsinformationen intakt zu halten, wenn die Entitäten nicht in Objektform vorliegen. Daher ist es oft pragmatisch, für diesen Zweck Fremdschlüsseleigenschaften im .NET-Typ beizubehalten. Fremdschlüsseleigenschaften können privat sein. Dies ist oft ein guter Kompromiss, um die Offenlegung des Fremdschlüssels zu vermeiden und gleichzeitig zu ermöglichen, dass sein Wert mit der Entität übertragen wird.

In Anlehnung an die beiden vorherigen Beispiele entfernt dieses Beispiel die Fremdschlüsseleigenschaft aus dem abhängigen Entitätstyp. EF erstellt daher eineSchatten-FremdschlüsseleigenschaftangerufenBlogIdvom Typint.

Ein wichtiger Punkt, den es hier zu beachten gilt, ist FolgendesC#-Nullable-Referenztypenwerden verwendet, sodass die NULL-Zulässigkeit der Referenznavigation verwendet wird, um zu bestimmen, ob die Fremdschlüsseleigenschaft NULL-Werte zulässt und ob die Beziehung daher optional oder erforderlich ist. Wenn keine Referenztypen verwendet werden, die NULL-Werte zulassen, ist die Schattenfremdschlüsseleigenschaft standardmäßig NULL-fähig, sodass die Beziehung standardmäßig optional ist. In diesem Fall verwenden SieIst erforderlichum zu erzwingen, dass die Schatten-Fremdschlüsseleigenschaft nicht nullbar ist, und um die Beziehung erforderlich zu machen.

Nach wie vor ist diese Beziehungdurch Konvention entdeckt. Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasForeignKey("BlogId") .IsRequired();}

Optional eins-zu-viele mit Schattenfremdschlüssel

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } öffentlicher Blog? Blog { get; Satz; } // Optionale Referenznavigation zum Prinzipal}

Wie im vorherigen Beispiel wurde die Fremdschlüsseleigenschaft aus dem abhängigen Entitätstyp entfernt. EF erstellt daher eineSchatten-FremdschlüsseleigenschaftangerufenBlogIdvom Typint?. Im Gegensatz zum vorherigen Beispiel wird die Fremdschlüsseleigenschaft dieses Mal als Nullable-Eigenschaft erstellt, weilC#-Nullable-Referenztypenwerden verwendet und die Navigation auf dem abhängigen Entitätstyp ist nullbar. Dadurch wird die Beziehung optional.

Wenn keine C#-Nullable-Referenztypen verwendet werden, wird die Fremdschlüsseleigenschaft standardmäßig auch als Nullable erstellt. Dies bedeutet, dass Beziehungen mit automatisch erstellten Schatteneigenschaften standardmäßig optional sind.

Nach wie vor ist diese Beziehungdurch Konvention entdeckt. Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasForeignKey("BlogId") .IsRequired(false); }

Eins-zu-viele ohne Navigation zum Prinzipal

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft}

In diesem Beispiel wurde die Fremdschlüsseleigenschaft wieder eingeführt, aber die Navigation auf der abhängigen Eigenschaft wurde entfernt.

Nach wie vor ist diese Beziehungdurch Konvention entdeckt. Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne() .HasForeignKey(e => e.BlogId) .IsRequired();}

Beachten Sie, dass der Aufruf anMit einerhat keine Argumente. Auf diese Weise teilen Sie EF mit, dass keine Navigation erfolgtPostZuBlog.

Wenn die Konfiguration von der Entität ohne Navigation ausgeht, muss der Typ der Entität am anderen Ende der Beziehung explizit mithilfe des Generikums angegeben werdenHasOne<>()Anruf. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasOne() .WithMany(e => e.Posts) .HasForeignKey(e => e.BlogId) .IsRequired();}

Eins-zu-viele ohne Navigation zum Prinzipal und mit Schattenfremdschlüssel

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; }}

Dieses Beispiel kombiniert zwei der vorherigen Beispiele, indem sowohl die Fremdschlüsseleigenschaft als auch die Navigation auf der abhängigen Eigenschaft entfernt werden.

Diese Beziehung istdurch Konvention entdecktals optionale Beziehung. Da der Code nichts enthält, was darauf hinweisen könnte, dass dies erforderlich sein sollte, ist eine minimale Konfiguration erforderlichIst erforderlichwird benötigt, um eine erforderliche Beziehung herzustellen. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne() .IsRequired();}

Eine umfassendere Konfiguration kann verwendet werden, um die Navigation und den Fremdschlüsselnamen mit einem entsprechenden Aufruf von explizit zu konfigurierenIst erforderlich()oderIsRequired(false)wie benötigt. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne() .HasForeignKey("BlogId") .IsRequired();}

Eins-zu-viele ohne Navigation zu abhängigen Personen

// Principal (parent)public class Blog{ public int Id { get; Satz; }}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft public Blog Blog { get; Satz; } = null!; // Erforderliche Referenznavigation zum Prinzipal}

Die beiden vorherigen Beispiele hatten Navigationen vom Prinzipal zu den abhängigen Elementen, aber keine Navigation vom abhängigen zum Prinzipal. Für die nächsten Beispiele wird die Navigation auf der abhängigen Seite wieder eingeführt, während die Navigation auf der Hauptseite stattdessen entfernt wird.

Nach wie vor ist diese Beziehungdurch Konvention entdeckt. Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasOne(e => e.Blog) .WithMany() .HasForeignKey(e => e.BlogId) .IsRequired();}

Beachten Sie das noch einmalMit vielen()wird ohne Argumente aufgerufen, um anzuzeigen, dass keine Navigation in diese Richtung erfolgt.

Wenn die Konfiguration von der Entität ohne Navigation ausgeht, muss der Typ der Entität am anderen Ende der Beziehung explizit mithilfe des Generikums angegeben werdenHasMany<>()Anruf. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany() .WithOne(e => e.Blog) .HasForeignKey(e => e.BlogId) .IsRequired();}

Eins-zu-viele ohne Navigation

Gelegentlich kann es sinnvoll sein, eine Beziehung ohne Navigationen zu konfigurieren. Eine solche Beziehung kann nur manipuliert werden, indem der Fremdschlüsselwert direkt geändert wird.

// Principal (parent)public class Blog{ public int Id { get; Satz; }}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft}

Diese Beziehung wird durch Konventionen nicht erkannt, da es keine Navigationen gibt, die darauf hinweisen, dass die beiden Typen verwandt sind. Es kann explizit in konfiguriert werdenOnModelCreating. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany() .WithOne();}

Mit dieser Konfiguration ist diePost.BlogIdDie Eigenschaft wird weiterhin konventionsgemäß als Fremdschlüssel erkannt und die Beziehung ist erforderlich, da für die Fremdschlüsseleigenschaft keine Nullwerte zulässig sind. Die Beziehung kann „optional“ gemacht werden, indem die Fremdschlüsseleigenschaft auf Null gesetzt wird.

Eine vollständigere explizite Konfiguration dieser Beziehung ist:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany() .WithOne() .HasForeignKey(e => e.BlogId) .IsRequired();}

Eins-zu-viele mit alternativem Schlüssel

In allen bisherigen Beispielen ist die Fremdschlüsseleigenschaft des abhängigen Schlüssels auf die Primärschlüsseleigenschaft des Hauptschlüssels beschränkt. Der Fremdschlüssel kann stattdessen auf eine andere Eigenschaft beschränkt werden, die dann zu einem Alternativschlüssel für den Hauptentitätstyp wird. Zum Beispiel:

// Principal (parent)public class Blog{ public int Id { get; Satz; } public int AlternateId { get; Satz; } // Alternativer Schlüssel als Ziel des Post.BlogId-Fremdschlüssels public ICollection Posts { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft public Blog Blog { get; Satz; } = null!; // Erforderliche Referenznavigation zum Prinzipal}

Diese Beziehung wird nicht durch Konventionen entdeckt, da EF immer durch Konventionen eine Beziehung zum Primärschlüssel herstellen wird. Es kann explizit in konfiguriert werdenOnModelCreatingmit einem Anruf anHasPrincipalKey. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasPrincipalKey(e => e.AlternateId);}

HasPrincipalKeykann mit anderen Aufrufen kombiniert werden, um die Navigationen, Fremdschlüsseleigenschaften und die erforderliche/optionale Natur explizit zu konfigurieren. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasPrincipalKey(e => e.AlternateId) .HasForeignKey( e => e.BlogId) .IsRequired();}

Eins-zu-viele mit zusammengesetztem Fremdschlüssel

In allen bisherigen Beispielen bestand die Primär- oder Alternativschlüsseleigenschaft des Prinzipals aus einer einzigen Eigenschaft. Primär- oder Alternativschlüssel können auch aus mehr als einer Eigenschaft gebildet werden – diese werden als bezeichnet„Zusammengesetzte Schlüssel“. Wenn der Hauptschlüssel einer Beziehung einen zusammengesetzten Schlüssel hat, muss der Fremdschlüssel der abhängigen Beziehung ebenfalls ein zusammengesetzter Schlüssel mit der gleichen Anzahl von Eigenschaften sein. Zum Beispiel:

// Principal (parent)public class Blog{ public int Id1 { get; Satz; } // Zusammengesetzter Schlüssel Teil 1 public int Id2 { get; Satz; } // Zusammengesetzter Schlüssel Teil 2 public ICollection Posts { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId1 { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft Teil 1 public int BlogId2 { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft Teil 2 public Blog Blog { get; Satz; } = null!; // Erforderliche Referenznavigation zum Prinzipal}

Diese Beziehung wird durch Konvention entdeckt. Der zusammengesetzte Schlüssel selbst muss jedoch explizit konfiguriert werden:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasKey(e => new { e.Id1, e.Id2 });}

BeideHasForeignKeyUndHasPrincipalKeykann verwendet werden, um Schlüssel mit mehreren Eigenschaften explizit anzugeben. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity( nestedBuilder => { nestedBuilder.HasKey(e => new { e.Id1, e.Id2 }); nestedBuilder.HasMany(e => e.Posts) .WithOne(e => e.Blog) .HasPrincipalKey(e => new { e.Id1, e.Id2 }) .HasForeignKey(e => new { e.BlogId1, e.BlogId2 }) .IsRequired(); } );}

Erforderlich Eins-zu-Viele ohne Kaskadenlöschung

// Principal (parent)public class Blog{ public int Id { get; Satz; } public ICollection Beiträge { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}// Abhängige (untergeordnete) öffentliche Klasse Post{ public int Id { get; Satz; } public int BlogId { get; Satz; } // Erforderliche Fremdschlüsseleigenschaft public Blog Blog { get; Satz; } = null!; // Erforderliche Referenznavigation zum Prinzipal}

Konventionell sind erforderliche Beziehungen so konfiguriertKaskadenlöschung; Dies bedeutet, dass beim Löschen des Prinzipals auch alle seine abhängigen Elemente gelöscht werden, da abhängige Elemente ohne einen Prinzipal nicht in der Datenbank existieren können. Es ist möglich, EF so zu konfigurieren, dass eine Ausnahme ausgelöst wird, anstatt automatisch abhängige Zeilen zu löschen, die nicht mehr vorhanden sein können:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasMany(e => e.Posts) .WithOne(e => e.Blog) .OnDelete(DeleteBehavior.Restrict);}

Selbstreferenzierung Eins-zu-Viele

In allen vorherigen Beispielen unterschied sich der Hauptentitätstyp vom abhängigen Entitätstyp. Dies muss nicht der Fall sein. Zum Beispiel in den folgenden Typen, jeweilsMitarbeiterhängt mit anderen zusammenMitarbeiter.

öffentliche Klasse Employee{ public int Id { get; Satz; } public int? ManagerId { get; Satz; } // Optionale Fremdschlüsseleigenschaft public Employee? Manager { get; Satz; } // Optionale Referenznavigation zum Prinzipal public ICollection Reports { get; } = new List(); // Sammlungsnavigation mit abhängigen Elementen}

Diese Beziehung istdurch Konvention entdeckt. Für Fälle, in denen die Navigation, der Fremdschlüssel oder die erforderliche/optionale Art der Beziehung nicht durch Konvention erkannt werden, können diese Dinge explizit konfiguriert werden. Zum Beispiel:

protected override void OnModelCreating(ModelBuilder modelBuilder){ modelBuilder.Entity() .HasOne(e => e.Manager) .WithMany(e => e.Reports) .HasForeignKey(e => e.ManagerId) .IsRequired( FALSCH);}