Bei Verwendung von Entity Framework Code First 4.3.1 können Beziehungen mit einer Multiplizität von 1: 1 erstellt werden. Das heißt, eine Entität an jedem Ende der Beziehung.
Es ist möglich, 1-zu-1-Beziehungen so zu konfigurieren, dass sie erforderlich-erforderlich oder erforderlich-optional ^ sind. Wenn ich jedoch zwischen den beiden wechsle, sehe ich keine Unterschiede in:
Als solcher kann ich einen RequiredPrincipalAs Datensatz ohne einen entsprechenden RequiredDependentAs Datensatz erstellen, obwohl die Beziehung als erforderlich-erforderlich konfiguriert ist . Dies scheint der Dokumentation für HasRequired (...) zu widersprechen:
Konfiguriert eine erforderliche Beziehung von diesem Entitätstyp. Instanzen des Entitätstyps können nur dann in der Datenbank gespeichert werden, wenn diese Beziehung angegeben ist. Der Fremdschlüssel in der Datenbank ist nicht nullfähig.
Die erforderlichen erforderlichen Beziehungsentitäten:
%Vor%Die erforderlichen-optionalen Beziehungsentitäten:
%Vor%Die DbContext- und Modellkonfiguration:
%Vor%Der Testcode:
%Vor%Ich bin mir bewusst, dass ich ein [Erforderlich] Datenattribut zu den Navigationseigenschaften von ErforderlichPrincipalA.DependentA und ErforderlichDependentA.PrincipalA hinzufügen könnte. Dies würde dazu führen, dass die EF-Validierung das obige Szenario verhindert. Ich möchte dies jedoch nicht tun, da es außerdem überprüft, ob die Navigationseigenschaft beim Aktualisieren einer vorhandenen Entität ausgefüllt wird. Dies bedeutet, dass die Anwendung die Entität am anderen Ende der Beziehung für jede Aktualisierung vorab abrufen muss.
Warum sehe ich keinen Unterschied im Verhalten von EF, wenn nur eine Beziehung zwischen erforderlich-erforderlich und erforderlich-optional geändert wird?
^ Beachten Sie, dass optional-optional ebenfalls unterstützt wird, aber dies ist nicht Teil meiner Frage. Es gibt offensichtliche Unterschiede im generierten Datenbankschema und im Laufzeitverhalten, wenn eine optional-optionale Beziehung konfiguriert ist.
Ich weiß nicht, warum "required-required" für diesen Fall erlaubt ist, aber es kann nicht in der Datenbank existieren, weil die Beziehung auf Primärschlüsseln aufgebaut ist. Required-required bedeutet, dass A nicht eingefügt werden kann, wenn das verwandte B nicht existiert und B nicht eingefügt werden kann, wenn das verwandte A nicht existiert = & gt; weder A noch B können eingefügt werden.
Datenbankbeziehung hat immer prinzipielle und abhängige Entität - Prinzipal kann immer ohne Abhängigkeit existieren.
Real required-required in EF kann nur erreicht werden, wenn A und B derselben Tabelle zugeordnet sind ( Tabellensplitting ), da in diesem Fall beide mit einem einzigen Einfügebefehl eingefügt werden.
Nicht wirklich eine Antwort, aber ich habe mehr zu sagen als in Kommentaren passen. Aber weißt du, ich schreibe 900 Seitenbücher ... so rolle ich. :)
Seltsamerweise würde ich erwarten, dass sich die fließende Konfiguration genauso verhält wie die Datenannotation und ich bin verwirrt, dass sie es nicht tut. (Ich habe Rowan Miller mit einem Link zu diesem Thread gepingt, um seine Rückmeldung zu erhalten.) Und das Verhalten, das ich meine, ist: Validierung der Einschränkung während SaveChanges.
Auf der Datenbankseite bin ich mit Ladislav. Im EF definiert EF das 1: 1 mit den Schlüsseln der zugehörigen Entitäten. In der Datenbank können Sie jedoch keine FKs in beiden Tabellen haben. Daher benötigt nur die abhängige Tabelle in der Datenbank diese Einschränkung, die PK einer vorhandenen PK in der Haupttabelle zuordnet.
Und schließlich verstehe ich Ihren Grund dafür, dass Sie nicht wollen, dass EF die Beziehung durchsetzt, wenn Sie sich nicht immer mit der ganzen Grafik beschäftigen. Ich denke, 1: 1-Beziehungen sind die verwirrendste der EF-Beziehungszuordnungen, und ich merke immer wieder, dass ich an Regeln denken muss und daran, wie die Dinge funktionieren sollen.
Tags und Links entity-framework