Ich habe die Situation, dass ein Benutzer mehrere Adressen haben kann. Dementsprechend habe ich eine ICollection für meine Benutzerklasse. Ich möchte aber auch, dass der Benutzer eine Standardadresse auswählen kann. Also habe ich folgendes gemacht:
%Vor% Ich mag das public virtual Address DefaultAddress { get; set; } ganz entfernen, die DefaultAddressId zu halten und wo es die Fluent API statt, da die aktuelle Setup eine Menge Ärger verursacht (in diesem und in anderen Klassen, in denen ich ein ähnliches Setup). Also kann dies mit der flüssigen api?
UPDATE: Die Adressklasse hat derzeit keinen Verweis auf die Benutzerklasse, es handelt sich um eine unidirektionale Beziehung. Aber ja, eine Adresse gehört nur einem Benutzer, es ist keine Beziehung von vielen zu vielen. Hier ist die Adressklasse:
%Vor% Ich würde die Fremdschlüsselbeziehung persönlich von User nach Address verschieben und eine IsDefaultAddress -Eigenschaft in die Adressklasse einfügen.
EF wird wissen, dass es eine Foreign Key Relation zwischen Address und User benötigt.
Dies würde Ihr Modell sehr vereinfachen. Das ist natürlich, wenn eine Adresse nur zu einem Benutzer gehören kann (wie von Slauma in den Kommentaren gefragt).
Ihr ursprüngliches Modell in der Frage sollte funktionieren. Du kannst es ganz einfach testen:
Programm.cs:
%Vor%In SQL Server Express wird eine neue Datenbank namens "EFTestApp.Context" erstellt. Sie können Breakpoints für alle oben aufgeführten SaveChanges setzen, über die Änderungen in der DB gehen und sie sich ansehen.
Wenn Sie sich die Beziehungen in der Datenbank ansehen, gibt es zwei, und in der Tabelle Addresses in der Datenbank befindet sich eine Fremdschlüsselspalte User_Id .
Ich denke, du könntest auch public int? DefaultAddressId { get; set; } und [ForeignKey("DefaultAddressId")] entfernen. Es erstellt die gleichen Datenbanktabellen und -beziehungen mit einer optionalen DefaultAddress.
Vielleicht möchten Sie die Beziehung Address -> User nach Bedarf (Adressen können nicht alleine in der DB ohne Benutzer leben). Dann können Sie dies der Context-Klasse hinzufügen:
Er macht User_Id in der Tabelle Addresses nicht nullable und richtet kaskadierendes Löschen standardmäßig ein. Wenn also ein Benutzer gelöscht wird, werden auch alle seine Adressen gelöscht.
DefaultAddressId benötigt keine spezifische Zuordnung, da es nur eine Spalte in User table ohne irgendeine Beziehung (FK) zu Address table ist. Es wird keine Beziehung erstellt, da die Navigationseigenschaft auf keiner Seite existiert. Es sollte auch eine Eins-zu-eins-Beziehung sein, die nicht funktioniert, weil EF keine eindeutigen Schlüssel unterstützt.
Ich mag die Lösung von @Sergi Papaseit
Tags und Links entity-framework entity-framework-4.1 ef-code-first fluent-interface