EF Core - Relationships (One to One, Zero?)

Nabend,

ich bastel mir gerade eine DB zusammen mit EF Core 2.1.

Ich habe zwei Klassen:

public class RD_User
{
    [Key]
    public Guid Id { get; set; }
}

public class RD_Class
{
    [Key]
    public Guid Id { get; set; }

    public Guid CreatedById { get; set; }


    public Guid ModifiedById { get; set; }



    [ForeignKey("CreatedById")]
    public RD_User CreatedBy { get; set; }
    [ForeignKey("ModifiedById")]
    public RD_User ModifiedBy { get; set; }
}

Habe ich bspw. "ModifiedBy" auskommentiert, funktioniert die Migration.
Migriere ich das mit der Property, bekomme ich einen Fehler, der im Endeffekt sagt, dass es zwei Relations gibt und nicht weiß, was zu was gehört. (Internet: Stichwort "InverseProperty". Aber ich habe in der User Class keine.)

Genaue Exception:> Fehlermeldung:

System.Data.SqlClient.SqlException: 'Introducing FOREIGN KEY constraint 'FK_Classes_Users_ModifiedById' on table 'Classes' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint or index. See previous errors.'

Im Internet finde ich keine Lösung, ohne zusätzliche Properties zu erstellen, um das Problem zu lösen.
Weil ich in der User Class eig. keine weiteren Properties dazu haben möchte, weil ich die beiden Properties in Class in n Klassen haben möchte.

Habt Ihr eine Idee?

Mit der Fluent API funktioniert es auch nicht.

Grüße

P.S.:
Kennt Ihr ein Beispiel, wie ich z.B. auf die gleiche Klasse referenzieren kann?
Also wenn ich die beiden Properties in RD_User ebenfalls einfüge und auf die gleiche Klasse referenziere. Habe dazu auch noch keinen Ansatz gefunden.

Hi,

grundlegendes Feedback: den Code kannst so eigentlich verwerfen. 😦

Nur weil man mit Datenbanken programmiert, sollte man nicht alle Empfehlungen, Richtilinien und Best Practises über Bord werfen. 👍
Der Code verstößt aber so ziemlich gegen alle Grundprinzipien (in .NET) 🙂

• Die Klasse sollte eher UserEntity statt RD_User heissen; RD_User würde ohnehin gegen jede Namenskonvention verstoßen - vor allem die von EF Core (von RD_Class ganz zu schweigen).
• Attribute sollte man seit rund 5 Jahren nicht mehr verwenden. Es wird seit Jahren aktiv Fluent Mapping empfohlen. Sie werden nur noch aus Legacy Gründen überhaupt unterstützt - würde damit rechnen (und ich hoffe es sehr!), dass sie einfach bald ganz raus fliegen.
• Die Magic Strings kann mit nameof() sehr simpel vermeiden

Das Mapping in Fluent sollte immer von der logischen Zielklasse einer Relation ausgehen.
In 99,9999% aller Fälle löst das jegliche Cascading-Errors.
In Deinem Fall fehlt der Rückkanal der Navigation.

Danke für deine Antwort und dein Feedback.

Die Klasse sollte eher UserEntity statt RD_User heissen; RD_User würde ohnehin gegen jede Namenskonvention verstoßen - vor allem die von EF Core (von RD_Class ganz zu schweigen).

Ich finde zu EF Core keine Namenskonventionen und habe davon auch nichts gelesen.

Aber mein eigentliches Problem habe ich auch gelöst bekommen.

Grüße

Ich finde zu EF Core keine Namenskonventionen und habe davon auch nichts gelesen.

Nur weil man mit Datenbanken programmiert, sollte man nicht alle Empfehlungen, Richtilinien und Best Practises über Bord werfen.

.NET General Naming Conventions

Und wenn man das zusätzlich auf die Best Practises von Software Architektur mapped, dann kann niemals RD_User raus kommen; sondern zB. UserEntity 😉