In diesem Post sehen wir uns an, wie wir mit Hilfe von Fluent API, Konventionen und Attributen zu einer übersetzbaren Definition von Entitäten kommen. Übersetzbar meint hier, wie wir die Entitäten und Beziehungen im Code definieren, um diese dann in SQL Tabellen übersetzen zu können. 

Dafür schauen wir uns diese wie folgt an:

  • Konventionen
  • Fluent API –> Property und Foreign Key
  • Attribute –> Property und Foreign Key
  • Welche sollte bevorzugt werden?

Grundlage für die Entitäten ist die Beispielapplikation.
Weitere Themen im Bereich Entity framework Core findest du auf der Übersichttsseite.
Oder in dem online Kurs zu diesem Thema.

Konventionen

Konventionen werden in Entity Framework angewendet um verschiedenste Dinge zu definieren.

Dazu gehören:

  • Tabellennamen – Entsprechen dem Klassennamen
  • Primärschlüssel – Eine Property vom Typ int, long oder Guid mit dem Propertynamen Id oder <$Klasse>Id
  • Fremdschlüssel – Eine Property vom Typ int, long oder Guid mit dem Namen der Entity dessen Schlüssel referenziert wird. Der Name sollte dann <$AndereEntity>Id heißen
  • Außerdem gibt es für jeden Datentyp noch abhängig vom Provider einzelne Konventionen. Z.B. wie Strings als varchar oder Text definiert werden usw.

Attribute

Eine zweite Methode zum definieren von Datenbankspezifika ist die Verwendung der Attribute im Namensraum Data Annotations.

Diese lassen sich in zwei Kategorien aufteilen:

  • Schema Atribute
    • Table  erlaubt den Tabellennamen zu spezifizieren 
    • ForeignKey – Dekorierte Property wird als ForeignKey genutzt
    • Column – Definiere den genutzten Spaltennamen in der Db
    • NotMapped – Property wird nicht in der DB berücksichtigt
  • Component Attribute
    • Key – Definiere den Primärschlüssel
    • Required – Property ist Not Null Spalte in der Db
    • MaxLength – Max Length einer String property definieren
    • ConcurrencyCheck – Property wird bei Concurrencychecks berücksichtigt

Fluent API

Neben Konventionen und Attributen haben wir ebenfalls noch die Fluent API zum konfigurieren unserer Entitäten.

Diese benötigen wir außerdem, um auf alle Definitionsmöglichkeiten zuzugreifen. Anders gesagt, mit der Fluent API können wir alles definieren, während wir mit Attributen nur auf ein Subset davon zugreifen können.

Siehe unter anderem in diesen Posts für mehr Informationen zum anwenden der FLuent API für Definitionen.

Ist eine Methode besser als die andere?

Mit den Attributen ist es möglich direkt an den Entitäten die Namen und Schema relevanten Anpassungen vorzunehmen.

Da Attribute aber nur ein Subset darstellen, benötigt man in den allermeisten Fällen sowieso die Fluent API und dann ziehe ich persönlich es vor die gesamte Konfiguration eines Typs an einer Stelle im Code vorzunehmen.

Dies kann man sogar in einer eigens dafür ausgelagerten Datei erstellen, welche die  IEntityTypeConfiguration<T> Schnittstelle implementiert.

Dazu aber mehr in einem anderen Post.

Categories: ef-core-de

0 Comments

Leave a Reply