EF-core-eins-zu-viele-Beziehungen HasOne().WithMany() vs HasMany().WithOne()
Sagen wir, ich habe die folgenden 2 Modelle:
public class Blog
{
public int BlogId { get; set; }
public string Url { get; set; }
public List<Post> Posts { get; set; }
}
public class Post
{
public int PostId { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public Blog Blog { get; set; }
}
Nun, wenn ich will, um zu konfigurieren Sie die Modelle von Beziehungen in DbContext ist, gibt es einen Unterschied zwischen:
modelBuilder.Entity<Post>()
.HasOne(p => p.Blog)
.WithMany(b => b.Posts);
und
modelBuilder.Entity<Blog>()
.HasMany(b => b.Posts)
.WithOne(p => p.blog);
und wenn es eine diffrence, was ist es? soll ich schreiben beide oder nur einer von Ihnen?
Als Anmerkung: muss ich definieren von Fremdschlüsseln? Basierend auf meinem wissen über Datenbanken, Sie können nicht erstellen Sie Beziehungen ohne foreign keys, aber EF nicht erforderlich, dass Sie auf foreign-key-Felder. Also, wie funktioniert das EF-behandelt Beziehungen, ohne zu wissen, foreign keys? Tut es dazu führen, dass die Leistung fällt oder bugs?
InformationsquelleAutor soorena12 | 2016-09-30
Du musst angemeldet sein, um einen Kommentar abzugeben.
Du hast Recht, Sie schaffen Beziehungen in DbContext ohne Fremdschlüssel in der Datenbank.
Auch:
WithOne: eins-zu-Eins Beziehungen haben eine Referenz navigation-Eigenschaft auf beiden Seiten. Sie Folgen den gleichen Konventionen wie eins-zu-viele-Beziehungen, aber es ist ein eindeutiger index eingeführt, auf die die foreign key-Eigenschaft, um sicherzustellen, dass nur eine abhängige ist in Beziehung zu jedem einzelnen AUFTRAGGEBER.
Viele-zu-viele: Beziehungen ohne eine entity-Klasse, die zum darstellen der join-Tabelle noch nicht unterstützt. Jedoch, Sie können eine viele-zu-viele-Beziehung, indem Sie eine entity-Klasse für die join-Tabelle und Zuordnung zwei separate ein-zu-viele-Beziehungen.
Müssen Sie nur definieren Sie eine Beziehung, weil in einigen Fällen erstellen Sie eine Beziehung für die Eltern-Kind -, ohne navigation Eigenschaften (eine oder-Sammlung).
Für Ihr Beispiel: Sie fügen eine relation für die Blog -> Posten, weil Sie die navigation Eigenschaften in den beiden Objekten, die zwei Zeilen machen das gleiche, aber auf unterschiedliche Weise:
In diesem Fall gibt es nicht einen besseren Weg, Sie sind nur auf verschiedene Art und Weise zu erstellen, die die Beziehung zwischen zwei Objekten, in der Regel die Zuordnung, es wäre vom Kind zum Elternteil
"Sie können erstellen, Beziehungen in DbContext ohne Fremdschlüssel in der Datenbank." Dies ist nicht korrekt. EF wird die Einführung einer shadow-Eigenschaft, die nicht im Modell, sondern in der Datenbank.
Danke für dein feedback, ja, ich meine von der Anwendung her, die wir nicht caere etwa wenn es einen constraint in der Datenbank für die Beziehung, manchmal gibt es Leute, die Fragen, ob wir brauchen, um zu definieren, zuerst das Verhältnis von Datenbank-Seite
Ich fürchte, EFCore macht die Annahme, dass es immer eine Einschränkung in der Datenbank, weil, wenn man konfiguriert eine Beziehung mit .OnDelete(DeleteBehavior.Kaskade), das Verhalten nur kümmert sich um verfolgte abhängige Entitäten, während nicht nur sein soll, magisch kümmern cascade-delete foreign key. Lesen Sie diesen Artikel und beachten Sie die Kommentare unten: docs.microsoft.com/en-us/ef/core/saving/cascade-delete IMO, es war eine sehr kurzsichtige Entscheidung auf ein ORM zu verhängen bestimmte Erwartungen auf die Datenbankstruktur und Beschränkungen.
InformationsquelleAutor H. Herzl
Definieren Sie Ihre Modelle ohne foreign key-Eigenschaft. Jedoch, Entity Framework, Einführung einer shadow-Eigenschaft, die in der Datenbank.
Entsprechend der Dokumentation:
Es wird sicherlich in der Datenbank. Wieder, laut der Dokumentation:
Shadow properties are useful when there is data in the database that should not be exposed on the mapped entity types. They are most often used for foreign key properties, where the relationship between two entities is represented by a foreign key value in the database, but the relationship is managed on the entity types using navigation properties between the entity types.
Shadow Eigenschaften einer Entity Framework-Konzept, nicht um eine Datenbank-Konzept. Also Nein, Sie sind nicht "in der Datenbank." Ich erwähne das nur zur Klarheit für alle an diesem Thema geforscht.
Eigentlich, wenn Sie versucht, das Beispiel auf der EF-Core-Dokumentation verlinkt in meinem vorigen Kommentar finden Sie, dass EF erstellen Sie eine Spalte
BlogId
'in der Datenbank' auf TabellePosts
. Vielleicht reden wir über eine andere Sache, aber die shadow-Eigenschaft wird auf jeden Fall eine entsprechende Spalte in der Datenbank.Ich glaube, "shadow" Eigentum bedeutet, dass Sie nicht sehen, die Eigenschaft auf den Typ selbst. Aber es wird da sein in der Datenbank.
InformationsquelleAutor Knelis