EF Navigation

  • C#
  • .NET 7–8

Es gibt 3 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    EF Navigation

    Hallo,

    mal eine grundlegende Frage zu Navigation im Entityframework.

    In einer Datenbank baue ich eine Baumstruktur auf, d.h. Einträge können Kinder von anderen Einträgen sein und die Verweise gehen über die entsprechenden Primärschlüssel.

    C#-Quellcode

    1. public class Entity
    2. {
    3. public int Id { get; set; }
    4. public string? Name { get; set; }
    5. public int? ParentId { get; set; }
    6. // Navigation
    7. public virtual ICollection<Entity> Childs { get; set; } = new List<Entity>();
    8. public Entity? Parent { get; set; }
    9. }


    C#-Quellcode

    1. public class Context : DbContext
    2. {
    3. public virtual DbSet<Entity> Entities { get; set; }
    4. protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    5. {
    6. var fn = "navigation.db";
    7. optionsBuilder.UseSqlite($"Data Source={fn}");
    8. }
    9. }


    woher nimmt EF die Kenntnis, dass ParentId auf Id in anderen Datensätzen zeigt? EF macht alles richtig, nur ich weiß nicht warum.


    Man nennt das wohl "by convention", oder? Aber wie ist denn diese convention?

    Die initiale Migration legt korrekt den PK an und auch die Constraints. Ich denke nicht, dass das auf Hokus Pokus hinausläuft. :P


    Grüßle

    Quellcode

    1. Class A
    2. {
    3. ICollection<B>
    4. }
    erstellt eine 1:n Beziehung von A zu B
    ParentId wird nach Konvention auch automatisch der Fremdschlüssel von Parent, weil einerseits Id Schlüssel sind und Parent der Name von einem Datensatz in diesem Fall ein Entity.
    Diese Fremdschlüssel werden aber sogar automatisch erzeugt, wenn du jetzt zum Beispiel keine ParentId Property hättest.
    Das kann man aber alles glaube ich mit Attributen festlegen, wenn man sich auf Konventionen nicht verlassen mag oder kann.
    Ja, das mit den Attributen kenne ich, bzw. über OnModelConfiguring . Da ich auf diese Weisen alles "einstellen" bzw. "vorgeben" kann, ist das (für mich) auch verständlich.

    Mich hat nur gewundert, woher EF das alles weiß, wenn ich (vermeintlich) nichts vorgebe. Aber das scheint an den Namen der Properties zu liegen. Eine Propery Id wird als PK interpretiert und entsprechend eingerichtet, Id2 nicht. Parent und ParentId werden wohl auch automatisch verbandelt. Also habe ich EF doch Informationen über das Datenmodell gegeben, wenn auch nicht wissentlich.

    Besser ist es wohl aber mit Attributen oder eben OnModelConfiguring zu arbeiten.

    MasterQ schrieb:

    Besser ist es wohl aber mit Attributen oder eben OnModelConfiguring zu arbeiten.
    Glaub nicht.
    Design by Convention ist ein schöner Pattern, der sich steigender Beliebtheint erfreut.

    Mit Attributen, Konfigurationen und so weiter - da kocht jeder sein Süppchen, und dann hat man am Ende an 20 Stellen zu gucken, warum was nicht läuft.