dev.kaibel.net - Benutzerbeiträge [de]

Entity Framework Core (EF Core)

2026-09-09T13:21:57Z

PhilKa: /* EF Core gegenüber ADO.NET */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ===

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable"
|+ Beziehungstypen
|-
! Beziehung !! Beispiel
|-
| 1:1 || Benutzer und Benutzerprofil
|-
| 1:n || Kunde und Bestellungen
|-
| n:m || Produkte und Kategorien
|}

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable"
|+ Strategien zum Laden von Beziehungen
|-
! Strategie !! Beschreibung
|-
| Eager Loading || zusammengehörige Daten werden sofort mitgeladen
|-
| Explicit Loading || zusammengehörige Daten werden gezielt nachgeladen
|-
| Lazy Loading || Daten werden erst beim Zugriff auf die Navigation Property geladen
|}

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable"
| + Wichtige Befehle für EF-Core-Migrationen
|-
! Befehl !! Funktion
|-
| dotnet ef migrations add Name || neue Migration erzeugen
|-
| dotnet ef migrations list || vorhandene Migrationen anzeigen
|-
| dotnet ef migrations remove || letzte Migration entfernen
|-
| dotnet ef database update || Datenbank auf die neueste Migration aktualisieren
|-
| dotnet ef database update MigrationName || Datenbank auf eine bestimmte Migration setzen
|-
| dotnet ef migrations script || SQL-Skript für Migrationen erzeugen
|}

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable"
|+ Vergleich von Code First und Database First
|-
! Eigenschaft !! Code First !! Database First
|-
| Ausgangspunkt || C#-Modell || vorhandene Datenbank
|-
| Schemaerstellung || über EF Core und Migrationen || Datenbank existiert bereits
|-
| Geeignet für neue Anwendungen || sehr gut || eingeschränkt
|-
| Geeignet für Legacy-Datenbanken || möglich || sehr gut
|-
| Schemaänderungen || häufig über Migrationen || häufig datenbankseitig
|}

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable"
|+ Zusammenhang zwischen Entity State und Datenbankoperation
|-
! Entity State !! Typische Datenbankoperation
|-
| Added || INSERT
|-
| Modified || UPDATE
|-
| Deleted || DELETE
|-
| Unchanged || keine Änderung
|}

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable"
|+ Zuordnung von EF-Core-Komponenten zu bekannten Patterns
|-
! EF-Core-Komponente !! Ähnliches Entwurfsmuster
|-
| DbSet || Repository
|-
| DbContext || Unit of Work
|}

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:25:45Z

PhilKa:

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ===

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable"
|+ Beziehungstypen
|-
! Beziehung !! Beispiel
|-
| 1:1 || Benutzer und Benutzerprofil
|-
| 1:n || Kunde und Bestellungen
|-
| n:m || Produkte und Kategorien
|}

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable"
|+ Strategien zum Laden von Beziehungen
|-
! Strategie !! Beschreibung
|-
| Eager Loading || zusammengehörige Daten werden sofort mitgeladen
|-
| Explicit Loading || zusammengehörige Daten werden gezielt nachgeladen
|-
| Lazy Loading || Daten werden erst beim Zugriff auf die Navigation Property geladen
|}

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable"
| + Wichtige Befehle für EF-Core-Migrationen
|-
! Befehl !! Funktion
|-
| dotnet ef migrations add Name || neue Migration erzeugen
|-
| dotnet ef migrations list || vorhandene Migrationen anzeigen
|-
| dotnet ef migrations remove || letzte Migration entfernen
|-
| dotnet ef database update || Datenbank auf die neueste Migration aktualisieren
|-
| dotnet ef database update MigrationName || Datenbank auf eine bestimmte Migration setzen
|-
| dotnet ef migrations script || SQL-Skript für Migrationen erzeugen
|}

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable"
|+ Vergleich von Code First und Database First
|-
! Eigenschaft !! Code First !! Database First
|-
| Ausgangspunkt || C#-Modell || vorhandene Datenbank
|-
| Schemaerstellung || über EF Core und Migrationen || Datenbank existiert bereits
|-
| Geeignet für neue Anwendungen || sehr gut || eingeschränkt
|-
| Geeignet für Legacy-Datenbanken || möglich || sehr gut
|-
| Schemaänderungen || häufig über Migrationen || häufig datenbankseitig
|}

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable"
|+ Zusammenhang zwischen Entity State und Datenbankoperation
|-
! Entity State !! Typische Datenbankoperation
|-
| Added || INSERT
|-
| Modified || UPDATE
|-
| Deleted || DELETE
|-
| Unchanged || keine Änderung
|}

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable"
|+ Zuordnung von EF-Core-Komponenten zu bekannten Patterns
|-
! EF-Core-Komponente !! Ähnliches Entwurfsmuster
|-
| DbSet || Repository
|-
| DbContext || Unit of Work
|}

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:18:17Z

PhilKa: /* Code First und Database First im Vergleich */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable"
|+ Beziehungstypen
|-
! Beziehung !! Beispiel
|-
| 1:1 || Benutzer und Benutzerprofil
|-
| 1:n || Kunde und Bestellungen
|-
| n:m || Produkte und Kategorien
|}

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable"
|+ Strategien zum Laden von Beziehungen
|-
! Strategie !! Beschreibung
|-
| Eager Loading || zusammengehörige Daten werden sofort mitgeladen
|-
| Explicit Loading || zusammengehörige Daten werden gezielt nachgeladen
|-
| Lazy Loading || Daten werden erst beim Zugriff auf die Navigation Property geladen
|}

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable"
| + Wichtige Befehle für EF-Core-Migrationen
|-
! Befehl !! Funktion
|-
| dotnet ef migrations add Name || neue Migration erzeugen
|-
| dotnet ef migrations list || vorhandene Migrationen anzeigen
|-
| dotnet ef migrations remove || letzte Migration entfernen
|-
| dotnet ef database update || Datenbank auf die neueste Migration aktualisieren
|-
| dotnet ef database update MigrationName || Datenbank auf eine bestimmte Migration setzen
|-
| dotnet ef migrations script || SQL-Skript für Migrationen erzeugen
|}

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable"
|+ Vergleich von Code First und Database First
|-
! Eigenschaft !! Code First !! Database First
|-
| Ausgangspunkt || C#-Modell || vorhandene Datenbank
|-
| Schemaerstellung || über EF Core und Migrationen || Datenbank existiert bereits
|-
| Geeignet für neue Anwendungen || sehr gut || eingeschränkt
|-
| Geeignet für Legacy-Datenbanken || möglich || sehr gut
|-
| Schemaänderungen || häufig über Migrationen || häufig datenbankseitig
|}

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:15:59Z

PhilKa: /* Wichtige Migrationsbefehle */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable"
|+ Beziehungstypen
|-
! Beziehung !! Beispiel
|-
| 1:1 || Benutzer und Benutzerprofil
|-
| 1:n || Kunde und Bestellungen
|-
| n:m || Produkte und Kategorien
|}

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable"
|+ Strategien zum Laden von Beziehungen
|-
! Strategie !! Beschreibung
|-
| Eager Loading || zusammengehörige Daten werden sofort mitgeladen
|-
| Explicit Loading || zusammengehörige Daten werden gezielt nachgeladen
|-
| Lazy Loading || Daten werden erst beim Zugriff auf die Navigation Property geladen
|}

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable"
| + Wichtige Befehle für EF-Core-Migrationen
|-
! Befehl !! Funktion
|-
| dotnet ef migrations add Name || neue Migration erzeugen
|-
| dotnet ef migrations list || vorhandene Migrationen anzeigen
|-
| dotnet ef migrations remove || letzte Migration entfernen
|-
| dotnet ef database update || Datenbank auf die neueste Migration aktualisieren
|-
| dotnet ef database update MigrationName || Datenbank auf eine bestimmte Migration setzen
|-
| dotnet ef migrations script || SQL-Skript für Migrationen erzeugen
|}

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:14:03Z

PhilKa: /* Laden zusammengehöriger Daten */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable"
|+ Beziehungstypen
|-
! Beziehung !! Beispiel
|-
| 1:1 || Benutzer und Benutzerprofil
|-
| 1:n || Kunde und Bestellungen
|-
| n:m || Produkte und Kategorien
|}

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable"
|+ Strategien zum Laden von Beziehungen
|-
! Strategie !! Beschreibung
|-
| Eager Loading || zusammengehörige Daten werden sofort mitgeladen
|-
| Explicit Loading || zusammengehörige Daten werden gezielt nachgeladen
|-
| Lazy Loading || Daten werden erst beim Zugriff auf die Navigation Property geladen
|}

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:09:44Z

PhilKa: /* Beziehungen zwischen Entities */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable"
|+ Beziehungstypen
|-
! Beziehung !! Beispiel
|-
| 1:1 || Benutzer und Benutzerprofil
|-
| 1:n || Kunde und Bestellungen
|-
| n:m || Produkte und Kategorien
|}

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:08:14Z

PhilKa: /* Data Annotations */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable"
|+ Häufig verwendete Data Annotations
|-
! Attribut !! Bedeutung
|-
| [Key] || definiert einen Primärschlüssel
|-
| [Required] || markiert ein Pflichtfeld
|-
| [MaxLength] || definiert eine maximale Länge
|-
| [Column] || konfiguriert eine Datenbankspalte
|-
| [Table] || konfiguriert den Tabellennamen
|-
| [NotMapped] || Property wird nicht in der Datenbank gespeichert
|-
| [ForeignKey] || definiert beziehungsweise kennzeichnet einen Fremdschlüssel
|}

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T10:04:05Z

PhilKa:

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable"
|+ Möglichkeiten zum Testen von EF-Core-Anwendungen
|-
! Verfahren !! Eigenschaften
|-
| echte Testdatenbank || sehr realitätsnah
|-
| temporäre Datenbank || gut für automatisierte Integrationstests
|-
| SQLite In-Memory || relationale Datenbank im Arbeitsspeicher
|-
| EF-Core-InMemory-Provider || schnell, aber kein vollständiger Ersatz für eine relationale Datenbank
|-
| Testcontainer || echtes Datenbanksystem innerhalb eines Containers
|}

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable"
|+ Vor- und Nachteile von Soft Delete
|-
! Vorteile !! Nachteile
|-
| Daten können wiederhergestellt werden || Datenbank wächst dauerhaft weiter
|-
| Historie bleibt erhalten || Abfragen müssen gelöschte Datensätze berücksichtigen
|-
| Beziehungen bleiben nachvollziehbar || Unique Constraints können komplizierter werden
|-
| Auditing wird erleichtert || Datenschutz kann trotzdem physische Löschung erfordern
|}

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable"
|+ Häufige EF-Core-Probleme
|-
! Problem !! Typische Ursache
|-
| DbContext wurde bereits disposed || DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet
|-
| A second operation was started on this context || mehrere parallele Operationen verwenden denselben DbContext
|-
| Entity wird bereits getrackt || mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt
|-
| LINQ-Ausdruck kann nicht übersetzt werden || verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung
|-
| Migration passt nicht zur Datenbank || Schema und Migrationshistorie sind nicht synchron
|}

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"
|+ Vergleich zwischen Entity Framework Core und ADO.NET
|-
! Eigenschaft !! EF Core !! ADO.NET
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Abfragesprache || hauptsächlich LINQ || hauptsächlich SQL
|-
| Objekt-Mapping || automatisch || normalerweise manuell
|-
| Change Tracking || integriert || normalerweise manuell
|-
| Migrationen || integriert || nicht Bestandteil von ADO.NET
|-
| Kontrolle über SQL || geringer || sehr hoch
|-
| Entwicklungsaufwand || häufig geringer || häufig höher
|}

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable"
|+ Vergleich zwischen Entity Framework Core und Dappe
|-
! Eigenschaft !! EF Core !! Dapper
|-
| LINQ-Abfragen || Ja || normalerweise Nein
|-
| automatische SQL-Erzeugung || Ja || überwiegend Nein
|-
| Change Tracking || Ja || Nein
|-
| Migrationen || Ja || Nein
|-
| Beziehungen || umfangreiche Unterstützung || weitgehend manuell
|-
| Abstraktionsgrad || hoch || niedrig
|-
| Kontrolle über SQL || mittel bis hoch || sehr hoch
|-
| CRUD-Entwicklung || sehr komfortabel || stärker SQL-orientiert
|}

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable"
|+ Aktuell relevante EF-Core-Versionen
|-
! EF-Core-Version !! Zielframework !! Support
|-
| EF Core 10 || .NET 10 || bis 10. November 2028
|-
| EF Core 9 || .NET 8 || bis 10. November 2026
|-
| EF Core 8 || .NET 8 || bis 10. November 2026
|}

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:54:27Z

PhilKa: /* Fluent API */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

}
</syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:53:43Z

PhilKa: /* Konfiguration des Datenmodells */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable"
|+ Möglichkeiten zur Konfiguration eines EF-Core-Modells
|-
! Verfahren !! Beschreibung
|-
| Conventions || automatische Erkennung anhand von Namens- und Strukturkonventionen
|-
| Data Annotations || Konfiguration über Attribute an C#-Klassen und Properties
|-
| Fluent API || Konfiguration über C#-Methoden im ModelBuilder
|}

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:52:05Z

PhilKa: /* Entity States */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable"
|+ Zustände einer Entity im Change Tracker
|-
! Zustand !! Bedeutung
|-
| Detached || Entity wird vom DbContext nicht verfolgt
|-
| Unchanged || Entity wird verfolgt, wurde aber nicht verändert
|-
| Added || Entity soll neu eingefügt werden
|-
| Modified || Entity wurde verändert
|-
| Deleted || Entity soll gelöscht werden
|}

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:41:24Z

PhilKa: /* Asynchrone Datenbankzugriffe */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable"
|+ Beispiele synchroner und asynchroner EF-Core-Methoden
|-
! Synchron !! Asynchron
|-
| ToList() || ToListAsync()
|-
| First() || FirstAsync()
|-
| FirstOrDefault() || FirstOrDefaultAsync()
|-
| Single() || SingleAsync()
|-
| Count() || CountAsync()
|-
| SaveChanges() || SaveChangesAsync()
|}

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:39:21Z

PhilKa: /* Datenbankprovider */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
! Datenbanksystem !! NuGet-Paket
|-
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
|-
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
|-
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
|-
| EF-Core-In-Memory-Datenbank || Microsoft.EntityFrameworkCore.InMemory
|-
| PostgreSQL || Npgsql.EntityFrameworkCore.PostgreSQL
|-
| MySQL / MariaDB || beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:37:21Z

PhilKa: /* Object-Relational Mapping */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable"
|+ Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:35:35Z

PhilKa: /* Wichtige LINQ-Methoden */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable" style="margin:auto"
| + Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
| ! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable" style="margin:auto"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
|-
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:35:06Z

PhilKa: /* = Wichtige LINQ-Methoden */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable" style="margin:auto"
| + Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
| ! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable" style="margin:auto"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ===

{| class="wikitable"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
|-
| Where() || Datensätze filtern
|-
| Select() || Daten beziehungsweise Properties auswählen
|-
| OrderBy() || aufsteigend sortieren
|-
| OrderByDescending() || absteigend sortieren
|-
| ThenBy() || zusätzliche Sortierung definieren
|-
| FirstAsync() || ersten Datensatz zurückgeben
|-
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
|-
| SingleAsync() || genau einen Datensatz erwarten
|-
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
|-
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
|-
| CountAsync() || Datensätze zählen
|-
| SumAsync() || Summe berechnen
|-
| AverageAsync() || Durchschnitt berechnen
| -
| MinAsync() || Minimalwert bestimmen
|-
| MaxAsync() || Maximalwert bestimmen
|-
| ToListAsync() || Ergebnis als Liste laden
|}

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:33:59Z

PhilKa: /* = Wichtige LINQ-Methoden */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable" style="margin:auto"
| + Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
| ! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable" style="margin:auto"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ==

{| class="wikitable" style="margin:auto"
|+ Häufig verwendete LINQ-Methoden mit EF Core
|-
! Methode !! Funktion
| -
| Where() || Datensätze filtern
| -
| Select() || Daten beziehungsweise Properties auswählen
| -
| OrderBy() || aufsteigend sortieren
| -
| OrderByDescending() || absteigend sortieren
| -
| ThenBy() || zusätzliche Sortierung definieren
| -
| FirstAsync() || ersten Datensatz zurückgeben
| -
| FirstOrDefaultAsync() || ersten Datensatz oder Standardwert zurückgeben
| -
| SingleAsync() || genau einen Datensatz erwarten
| -
| SingleOrDefaultAsync() || genau einen Datensatz oder Standardwert erwarten
| -
| AnyAsync() || prüfen, ob mindestens ein Datensatz existiert
| -
| CountAsync() || Datensätze zählen
| -
| SumAsync() || Summe berechnen
| -
| AverageAsync() || Durchschnitt berechnen
| -
| MinAsync() || Minimalwert bestimmen
| -
| MaxAsync() || Maximalwert bestimmen
| -
| ToListAsync() || Ergebnis als Liste laden
| }

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:31:13Z

PhilKa: /* CRUD-Operationen */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable" style="margin:auto"
| + Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
| ! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable" style="margin:auto"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable"
|+ CRUD-Operationen
|-
! Abkürzung !! Bedeutung !! SQL-Entsprechung
|-
| Create || Datensatz anlegen || INSERT
|-
| Read || Datensatz lesen || SELECT
|-
| Update || Datensatz ändern || UPDATE
|-
| Delete || Datensatz löschen || DELETE
|}

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ==

{| class="wikitable" style="margin:auto"

| + Häufig verwendete LINQ-Methoden mit EF Core | | |
| --------------------------------------------- | - | ------------------------------------------------ |
| ! Methode !! Funktion | | |
| - | | |
| Where() | | Datensätze filtern |
| - | | |
| Select() | | Daten beziehungsweise Properties auswählen |
| - | | |
| OrderBy() | | aufsteigend sortieren |
| - | | |
| OrderByDescending() | | absteigend sortieren |
| - | | |
| ThenBy() | | zusätzliche Sortierung definieren |
| - | | |
| FirstAsync() | | ersten Datensatz zurückgeben |
| - | | |
| FirstOrDefaultAsync() | | ersten Datensatz oder Standardwert zurückgeben |
| - | | |
| SingleAsync() | | genau einen Datensatz erwarten |
| - | | |
| SingleOrDefaultAsync() | | genau einen Datensatz oder Standardwert erwarten |
| - | | |
| AnyAsync() | | prüfen, ob mindestens ein Datensatz existiert |
| - | | |
| CountAsync() | | Datensätze zählen |
| - | | |
| SumAsync() | | Summe berechnen |
| - | | |
| AverageAsync() | | Durchschnitt berechnen |
| - | | |
| MinAsync() | | Minimalwert bestimmen |
| - | | |
| MaxAsync() | | Maximalwert bestimmen |
| - | | |
| ToListAsync() | | Ergebnis als Liste laden |
| } | | |

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:25:57Z

PhilKa: /* CRUD-Operationen */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable" style="margin:auto"
| + Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
| ! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable" style="margin:auto"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable" style="margin:auto"
|+ CRUD-Operationen
|-
| ! Abkürzung !! Bedeutung !! SQL-Entsprechung
| -
| Create || Datensatz anlegen || INSERT
| -
| Read || Datensatz lesen || SELECT
| -
| Update || Datensatz ändern || UPDATE
| -
| Delete || Datensatz löschen || DELETE
| }

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ==

{| class="wikitable" style="margin:auto"

| + Häufig verwendete LINQ-Methoden mit EF Core | | |
| --------------------------------------------- | - | ------------------------------------------------ |
| ! Methode !! Funktion | | |
| - | | |
| Where() | | Datensätze filtern |
| - | | |
| Select() | | Daten beziehungsweise Properties auswählen |
| - | | |
| OrderBy() | | aufsteigend sortieren |
| - | | |
| OrderByDescending() | | absteigend sortieren |
| - | | |
| ThenBy() | | zusätzliche Sortierung definieren |
| - | | |
| FirstAsync() | | ersten Datensatz zurückgeben |
| - | | |
| FirstOrDefaultAsync() | | ersten Datensatz oder Standardwert zurückgeben |
| - | | |
| SingleAsync() | | genau einen Datensatz erwarten |
| - | | |
| SingleOrDefaultAsync() | | genau einen Datensatz oder Standardwert erwarten |
| - | | |
| AnyAsync() | | prüfen, ob mindestens ein Datensatz existiert |
| - | | |
| CountAsync() | | Datensätze zählen |
| - | | |
| SumAsync() | | Summe berechnen |
| - | | |
| AverageAsync() | | Durchschnitt berechnen |
| - | | |
| MinAsync() | | Minimalwert bestimmen |
| - | | |
| MaxAsync() | | Maximalwert bestimmen |
| - | | |
| ToListAsync() | | Ergebnis als Liste laden |
| } | | |

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]

Entity Framework Core (EF Core)

2026-09-09T09:22:32Z

PhilKa: /* Datenbankprovider */

{{DISPLAYTITLE:Entity Framework Core}}

'''Entity Framework Core''' (kurz '''EF Core''') ist ein modernes '''Object-Relational Mapping Framework''' (ORM) für .NET. Es ermöglicht .NET-Anwendungen den Zugriff auf relationale und teilweise auch nichtrelationale Datenbanken, ohne dass für jede Datenbankoperation manuell SQL geschrieben werden muss.

EF Core bildet Tabellen und Datensätze einer Datenbank auf C#-Klassen und Objekte ab. Datenbankabfragen können dabei überwiegend mit '''LINQ''' formuliert werden. Entity Framework Core übersetzt diese LINQ-Abfragen anschließend in die Abfragesprache des jeweiligen Datenbanksystems.

Entity Framework Core ist der moderne Nachfolger des klassischen '''Entity Framework''' und wurde speziell für das plattformübergreifende .NET entwickelt.

Mit EF Core können unter anderem Anwendungen für folgende Plattformen entwickelt werden:

* Windows
* Linux
* macOS
* Webserver mit ASP.NET Core
* Blazor
* Desktop-Anwendungen
* Worker Services
* Cloud-Anwendungen

Die aktuelle LTS-Generation ist '''Entity Framework Core 10''' und basiert auf '''.NET 10'''.

== Grundprinzip ==

Ohne ein ORM muss eine Anwendung SQL-Abfragen normalerweise selbst erstellen und die zurückgegebenen Daten anschließend manuell auf Objekte abbilden.

Eine SQL-Abfrage könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="sql">
SELECT Id, Name, Price
FROM Products
WHERE Price > 100;
</syntaxhighlight>

Anschließend müssten die zurückgegebenen Datensätze beispielsweise mit ADO.NET gelesen und in C#-Objekte umgewandelt werden.

Mit Entity Framework Core kann dieselbe Abfrage stattdessen mit LINQ formuliert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diese Abfrage in ein für den verwendeten Datenbankanbieter geeignetes SQL-Statement.

Das grundlegende Prinzip lautet:

<pre>
C#-Anwendung
│
▼
Entity Framework Core
│
▼
Datenbankprovider
│
▼
Datenbank
</pre>

Beim Lesen von Daten funktioniert die Verarbeitung entsprechend in die Gegenrichtung:

<pre>
Datenbank
│
▼
Datenbankprovider
│
▼
Entity Framework Core
│
▼
C#-Objekte
</pre>

== Object-Relational Mapping ==

EF Core gehört zur Kategorie der '''Object-Relational Mapper'''.

Ein ORM versucht, das objektorientierte Datenmodell einer Anwendung mit dem relationalen Datenmodell einer Datenbank zu verbinden.

{| class="wikitable" style="margin:auto"
| + Zuordnung zwischen Objektmodell und relationaler Datenbank
|-
| ! Objektorientierte Anwendung !! Relationale Datenbank
|-
| Klasse || Tabelle
|-
| Objekt || Datensatz / Tabellenzeile
|-
| Property || Spalte
|-
| Objekt-ID || Primärschlüssel
|-
| Referenz auf ein Objekt || Fremdschlüssel
|-
| Collection || Beziehung zu mehreren Datensätzen
|}

Eine einfache C#-Klasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

EF Core kann daraus beispielsweise eine Datenbanktabelle mit folgendem Aufbau erzeugen:

{| class="wikitable" style="margin:auto"
|+ Beispiel für die Tabelle Products
|-
! Id !! Name !! Price
|-
| 1 || Kalkammonsalpeter || 289,00
|-
| 2 || Harnstoff || 315,00
|-
| 3 || Kali 60 || 245,00
|}

== Wichtige Bestandteile von EF Core ==

Zu den zentralen Bestandteilen von Entity Framework Core gehören:

* '''Entity''' – C#-Klasse, die Daten eines bestimmten Typs repräsentiert
* '''DbContext''' – zentrale Schnittstelle zwischen Anwendung und Datenbank
* '''DbSet''' – repräsentiert eine Menge von Entities
* '''LINQ''' – Abfragesprache innerhalb von .NET
* '''Change Tracker''' – überwacht Änderungen an geladenen Entities
* '''Database Provider''' – stellt die Verbindung zu einem konkreten Datenbanksystem her
* '''Migrations''' – verwalten Änderungen am Datenbankschema
* '''Model Configuration''' – definiert die Abbildung zwischen C#-Modell und Datenbank
* '''Query Translation''' – übersetzt LINQ-Abfragen in SQL beziehungsweise die Abfragesprache des Providers

== Installation ==

EF Core wird normalerweise über '''NuGet''' in ein .NET-Projekt eingebunden.

=== Basispaket ===

Das grundlegende EF-Core-Paket kann über die Kommandozeile installiert werden:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore
</syntaxhighlight>

Zusätzlich wird normalerweise ein Datenbankprovider benötigt.

=== Microsoft SQL Server ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

=== SQLite ===

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
</syntaxhighlight>

=== Design-Paket ===

Für Migrationen und verschiedene Entwicklungswerkzeuge wird zusätzlich das Design-Paket benötigt:

<syntaxhighlight lang="text">
dotnet add package Microsoft.EntityFrameworkCore.Design
</syntaxhighlight>

=== dotnet-ef installieren ===

Für die Verwaltung von Migrationen über die Kommandozeile kann das Werkzeug '''dotnet-ef''' installiert werden:

<syntaxhighlight lang="text">
dotnet tool install --global dotnet-ef
</syntaxhighlight>

Eine vorhandene Installation kann aktualisiert werden:

<syntaxhighlight lang="text">
dotnet tool update --global dotnet-ef
</syntaxhighlight>

Die installierte Version kann überprüft werden:

<syntaxhighlight lang="text">
dotnet ef --version
</syntaxhighlight>

== Datenbankprovider ==

EF Core selbst enthält keine direkte Implementierung für jedes Datenbanksystem. Stattdessen werden sogenannte '''Database Provider''' verwendet.

Ein Provider übersetzt EF-Core-Operationen in Befehle für das jeweilige Datenbanksystem.

{| class="wikitable"
|+ Häufig verwendete Datenbankprovider
|-
| ! Datenbanksystem !! NuGet-Paket
| -
| Microsoft SQL Server / Azure SQL || Microsoft.EntityFrameworkCore.SqlServer
| -
| SQLite || Microsoft.EntityFrameworkCore.Sqlite
| - ||
| Azure Cosmos DB || Microsoft.EntityFrameworkCore.Cosmos
| -
| EF-Core-In-Memory-Datenbank | | Microsoft.EntityFrameworkCore.InMemory
| -
| PostgreSQL | | Npgsql.EntityFrameworkCore.PostgreSQL
| -
| MySQL / MariaDB | | beispielsweise Pomelo.EntityFrameworkCore.MySql
|}

Bei Drittanbieter-Providern muss darauf geachtet werden, dass die verwendete Version mit der eingesetzten EF-Core-Hauptversion kompatibel ist.

== Entity ==

Eine '''Entity''' ist normalerweise eine einfache C#-Klasse.

Beispiel:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

EF Core erkennt viele Eigenschaften anhand von Konventionen automatisch.

Die Property:

<syntaxhighlight lang="csharp">
public int Id { get; set; }
</syntaxhighlight>

wird beispielsweise standardmäßig als Primärschlüssel interpretiert.

Alternativ wird normalerweise auch:

<syntaxhighlight lang="csharp">
public int ProductId { get; set; }
</syntaxhighlight>

als Primärschlüssel der Entity <code>Product</code> erkannt.

== DbContext ==

Der '''DbContext''' ist die zentrale Komponente von Entity Framework Core.

Ein DbContext stellt eine Arbeitseinheit beziehungsweise Sitzung mit einer Datenbank dar.

Er ist unter anderem verantwortlich für:

* Datenbankabfragen
* Erstellen neuer Datensätze
* Ändern vorhandener Datensätze
* Löschen von Datensätzen
* Change Tracking
* Transaktionen
* Verwaltung des Datenmodells
* Ausführen von SaveChanges
* Verwaltung von Datenbankverbindungen

Ein einfacher DbContext kann folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;

public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();
```

} </syntaxhighlight>

== DbSet ==

Ein '''DbSet''' repräsentiert eine Menge von Entities eines bestimmten Typs.

Beispiel:

<syntaxhighlight lang="csharp">
public DbSet<Product> Products => Set<Product>();
</syntaxhighlight>

Über dieses DbSet können beispielsweise Produkte abgefragt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

Ein DbSet kann vereinfacht als objektorientierte Darstellung einer Datenbanktabelle betrachtet werden.

Dabei ist jedoch zu beachten, dass ein DbSet nicht zwangsläufig exakt einer einzelnen physischen Tabelle entsprechen muss.

== Verbindung zur Datenbank ==

Eine Datenbankverbindung wird normalerweise über einen '''Connection String''' definiert.

Ein Connection String für SQL Server könnte beispielsweise so aussehen:

<syntaxhighlight lang="text">
Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True
</syntaxhighlight>

In einer ASP.NET-Core-Anwendung wird der Connection String normalerweise in der Datei <code>appsettings.json</code> gespeichert.

<syntaxhighlight lang="json">
{
"ConnectionStrings": {
"DefaultConnection": "Server=localhost;Database=TestDb;Trusted_Connection=True;TrustServerCertificate=True"
}
}
</syntaxhighlight>

Anschließend kann der DbContext in <code>Program.cs</code> registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

== Dependency Injection ==

ASP.NET Core besitzt ein integriertes '''Dependency-Injection-System'''.

Der DbContext kann dort beispielsweise folgendermaßen registriert werden:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection"));
});
</syntaxhighlight>

Danach kann er in anderen Komponenten verwendet werden:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly ApplicationDbContext _context;

```
public ProductService(ApplicationDbContext context)
{
_context = context;
}
```

} </syntaxhighlight>

In klassischen ASP.NET-Core-Anwendungen entspricht die Lebensdauer eines solchen DbContext normalerweise einem HTTP-Request.

== CRUD-Operationen ==

CRUD steht für die vier grundlegenden Datenbankoperationen:

{| class="wikitable" style="margin:auto"

| + CRUD-Operationen | | | | |
| -------------------------------------------- | - | ----------------- | - | ------ |
| ! Abkürzung !! Bedeutung !! SQL-Entsprechung | | | | |
| - | | | | |
| Create | | Datensatz anlegen | | INSERT |
| - | | | | |
| Read | | Datensatz lesen | | SELECT |
| - | | | | |
| Update | | Datensatz ändern | | UPDATE |
| - | | | | |
| Delete | | Datensatz löschen | | DELETE |
| } | | | | |

=== Create ===

Eine neue Entity wird erzeugt:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};
</syntaxhighlight>

Anschließend wird sie dem DbContext hinzugefügt:

<syntaxhighlight lang="csharp">
context.Products.Add(product);
</syntaxhighlight>

Die Änderung wird mit:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

in die Datenbank geschrieben.

Komplettes Beispiel:

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Harnstoff",
Price = 315.00m,
Stock = 12000
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Read ===

Alle Produkte laden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Einen Datensatz anhand des Primärschlüssels suchen:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);
</syntaxhighlight>

Produkte anhand einer Bedingung filtern:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 300)
.ToListAsync();
</syntaxhighlight>

=== Update ===

Eine geladene Entity kann direkt verändert werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 299.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt über den Change Tracker, dass sich der Preis verändert hat.

=== Delete ===

Ein Datensatz kann folgendermaßen gelöscht werden:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== LINQ ==

'''Language Integrated Query''' – kurz '''LINQ''' – ist die wichtigste Abfragemethode für EF Core.

Eine typische LINQ-Abfrage sieht beispielsweise folgendermaßen aus:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

EF Core übersetzt diesen Ausdruck in eine SQL-Abfrage.

=== Deferred Execution ==

Viele LINQ-Abfragen werden zunächst nur definiert und noch nicht ausgeführt.

Beispiel:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Zu diesem Zeitpunkt wurde die Datenbank normalerweise noch nicht abgefragt.

Die Abfrage wird beispielsweise durch:

<syntaxhighlight lang="csharp">
var products = await query.ToListAsync();
</syntaxhighlight>

tatsächlich ausgeführt.

Dieses Verhalten wird als '''Deferred Execution''' bezeichnet.

=== Wichtige LINQ-Methoden ==

{| class="wikitable" style="margin:auto"

| + Häufig verwendete LINQ-Methoden mit EF Core | | |
| --------------------------------------------- | - | ------------------------------------------------ |
| ! Methode !! Funktion | | |
| - | | |
| Where() | | Datensätze filtern |
| - | | |
| Select() | | Daten beziehungsweise Properties auswählen |
| - | | |
| OrderBy() | | aufsteigend sortieren |
| - | | |
| OrderByDescending() | | absteigend sortieren |
| - | | |
| ThenBy() | | zusätzliche Sortierung definieren |
| - | | |
| FirstAsync() | | ersten Datensatz zurückgeben |
| - | | |
| FirstOrDefaultAsync() | | ersten Datensatz oder Standardwert zurückgeben |
| - | | |
| SingleAsync() | | genau einen Datensatz erwarten |
| - | | |
| SingleOrDefaultAsync() | | genau einen Datensatz oder Standardwert erwarten |
| - | | |
| AnyAsync() | | prüfen, ob mindestens ein Datensatz existiert |
| - | | |
| CountAsync() | | Datensätze zählen |
| - | | |
| SumAsync() | | Summe berechnen |
| - | | |
| AverageAsync() | | Durchschnitt berechnen |
| - | | |
| MinAsync() | | Minimalwert bestimmen |
| - | | |
| MaxAsync() | | Maximalwert bestimmen |
| - | | |
| ToListAsync() | | Ergebnis als Liste laden |
| } | | |

== Projektionen ==

Es ist häufig nicht notwendig, vollständige Entities aus der Datenbank zu laden.

Angenommen, eine Produktübersicht benötigt ausschließlich ID, Name und Preis.

Statt:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

kann eine Projektion verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new
{
p.Id,
p.Name,
p.Price
})
.ToListAsync();
</syntaxhighlight>

Noch sauberer ist häufig die Verwendung eines DTO:

<syntaxhighlight lang="csharp">
public class ProductListDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Select(p => new ProductListDto
{
Id = p.Id,
Name = p.Name,
Price = p.Price
})
.ToListAsync();
</syntaxhighlight>

Dadurch müssen nicht alle Spalten der Tabelle vom Datenbankserver übertragen werden.

== Asynchrone Datenbankzugriffe ==

Insbesondere bei Web- und Serveranwendungen sollten Datenbankzugriffe nach Möglichkeit asynchron ausgeführt werden.

Statt:

<syntaxhighlight lang="csharp">
var products = context.Products.ToList();
</syntaxhighlight>

wird normalerweise:

<syntaxhighlight lang="csharp">
var products = await context.Products.ToListAsync();
</syntaxhighlight>

verwendet.

{| class="wikitable" style="margin:auto"

| + Beispiele synchroner und asynchroner EF-Core-Methoden | | |
| ------------------------------------------------------- | - | --------------------- |
| ! Synchron !! Asynchron | | |
| - | | |
| ToList() | | ToListAsync() |
| - | | |
| First() | | FirstAsync() |
| - | | |
| FirstOrDefault() | | FirstOrDefaultAsync() |
| - | | |
| Single() | | SingleAsync() |
| - | | |
| Count() | | CountAsync() |
| - | | |
| SaveChanges() | | SaveChangesAsync() |
| } | | |

Asynchrone Operationen sind insbesondere bei Serveranwendungen wichtig, da der ausführende Thread während einer Datenbankoperation nicht unnötig blockiert werden muss.

== Change Tracking ==

EF Core überwacht standardmäßig Entities, die über einen DbContext geladen wurden.

Dies wird als '''Change Tracking''' bezeichnet.

Beispiel:

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(1);

if (product != null)
{
product.Price = 350;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

EF Core erkennt, dass sich die Property <code>Price</code> verändert hat.

Beim Aufruf von:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

wird daraus beispielsweise ein entsprechender UPDATE-Befehl erzeugt.

=== Entity States ===

Eine vom Change Tracker verwaltete Entity kann unterschiedliche Zustände besitzen.

{| class="wikitable" style="margin:auto"

| + Zustände einer Entity im Change Tracker | | |
| ----------------------------------------- | - | ------------------------------------------------ |
| ! Zustand !! Bedeutung | | |
| - | | |
| Detached | | Entity wird vom DbContext nicht verfolgt |
| - | | |
| Unchanged | | Entity wird verfolgt, wurde aber nicht verändert |
| - | | |
| Added | | Entity soll neu eingefügt werden |
| - | | |
| Modified | | Entity wurde verändert |
| - | | |
| Deleted | | Entity soll gelöscht werden |
| } | | |

Der aktuelle Zustand kann beispielsweise ermittelt werden:

<syntaxhighlight lang="csharp">
var state = context.Entry(product).State;
</syntaxhighlight>

== AsNoTracking ==

Wenn Daten ausschließlich gelesen werden und anschließend nicht verändert werden sollen, ist das Change Tracking häufig unnötig.

In diesem Fall kann <code>AsNoTracking()</code> verwendet werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

Dies kann:

* Speicher sparen
* den Verwaltungsaufwand reduzieren
* Read-Only-Abfragen beschleunigen

'''Faustregel:'''

Wenn geladene Entities nicht verändert und wieder gespeichert werden sollen, sollte geprüft werden, ob <code>AsNoTracking()</code> sinnvoll ist.

== Konfiguration des Datenmodells ==

EF Core bietet verschiedene Möglichkeiten zur Konfiguration des Datenmodells.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zur Konfiguration eines EF-Core-Modells | | |
| ------------------------------------------------------- | - | ------------------------------------------------------------------ |
| ! Verfahren !! Beschreibung | | |
| - | | |
| Conventions | | automatische Erkennung anhand von Namens- und Strukturkonventionen |
| - | | |
| Data Annotations | | Konfiguration über Attribute an C#-Klassen und Properties |
| - | | |
| Fluent API | | Konfiguration über C#-Methoden im ModelBuilder |
| } | | |

== Conventions ==

EF Core versucht zunächst, die Struktur eines Datenmodells automatisch zu erkennen.

Beispiel:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;
```

} </syntaxhighlight>

EF Core erkennt dabei automatisch:

* <code>Customer</code> als Entity
* <code>Id</code> als Primärschlüssel
* <code>Name</code> als Datenbankfeld

Diese automatische Konfiguration wird als '''Convention-based Configuration''' bezeichnet.

== Data Annotations ==

Eigenschaften einer Entity können über Attribute konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

public class Product
{
[Key]
public int Id { get; set; }

```
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;

[Column(TypeName = "decimal(10,2)")]
public decimal Price { get; set; }
```

} </syntaxhighlight>

{| class="wikitable" style="margin:auto"

| + Häufig verwendete Data Annotations | | |
| ------------------------------------ | - | ----------------------------------------------------------- |
| ! Attribut !! Bedeutung | | |
| - | | |
| [Key] | | definiert einen Primärschlüssel |
| - | | |
| [Required] | | markiert ein Pflichtfeld |
| - | | |
| [MaxLength] | | definiert eine maximale Länge |
| - | | |
| [Column] | | konfiguriert eine Datenbankspalte |
| - | | |
| [Table] | | konfiguriert den Tabellennamen |
| - | | |
| [NotMapped] | | Property wird nicht in der Datenbank gespeichert |
| - | | |
| [ForeignKey] | | definiert beziehungsweise kennzeichnet einen Fremdschlüssel |
| } | | |

== Fluent API ==

Die '''Fluent API''' bietet mehr Konfigurationsmöglichkeiten als Data Annotations.

Sie wird normalerweise innerhalb von:

<syntaxhighlight lang="csharp">
OnModelCreating()
</syntaxhighlight>

verwendet.

Beispiel:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

```
entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);
});
```

} </syntaxhighlight>

== IEntityTypeConfiguration ==

Bei größeren Anwendungen sollte die Konfiguration einzelner Entities häufig in separate Klassen ausgelagert werden.

Beispiel:

<syntaxhighlight lang="csharp">
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

public class ProductConfiguration
: IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.HasKey(p => p.Id);

```
builder.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

builder.Property(p => p.Price)
.HasPrecision(10, 2);
}
```

} </syntaxhighlight>

Die Konfigurationen können anschließend automatisch geladen werden:

<syntaxhighlight lang="csharp">
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(
typeof(ApplicationDbContext).Assembly);
}
</syntaxhighlight>

Diese Variante sorgt bei umfangreichen Datenmodellen für eine deutlich bessere Übersicht.

== Beziehungen zwischen Entities ==

Relationale Datenbanken arbeiten intensiv mit Beziehungen zwischen Tabellen.

EF Core unterstützt insbesondere:

* 1:1-Beziehungen
* 1:n-Beziehungen
* n:m-Beziehungen

{| class="wikitable" style="margin:auto"

| + Beziehungstypen | | |
| ----------------------- | - | --------------------------- |
| ! Beziehung !! Beispiel | | |
| - | | |
| 1:1 | | Benutzer und Benutzerprofil |
| - | | |
| 1:n | | Kunde und Bestellungen |
| - | | |
| n:m | | Produkte und Kategorien |
| } | | |

== 1:n-Beziehung ==

Ein Kunde kann mehrere Bestellungen besitzen.

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Order> Orders { get; set; }
= new List<Order>();
```

} </syntaxhighlight>

Die Bestellung enthält den Fremdschlüssel:

<syntaxhighlight lang="csharp">
public class Order
{
public int Id { get; set; }

```
public DateTime OrderDate { get; set; }

public int CustomerId { get; set; }

public Customer Customer { get; set; } = null!;
```

} </syntaxhighlight>

Dabei stellt:

<syntaxhighlight lang="csharp">
public int CustomerId { get; set; }
</syntaxhighlight>

den Fremdschlüssel dar.

Die Property:

<syntaxhighlight lang="csharp">
public Customer Customer { get; set; }
</syntaxhighlight>

ist eine '''Navigation Property'''.

== 1:1-Beziehung ==

Ein Benutzer kann beispielsweise genau ein Profil besitzen.

<syntaxhighlight lang="csharp">
public class User
{
public int Id { get; set; }

```
public string UserName { get; set; } = string.Empty;

public UserProfile? Profile { get; set; }
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class UserProfile
{
public int Id { get; set; }

```
public string Description { get; set; } = string.Empty;

public int UserId { get; set; }

public User User { get; set; } = null!;
```

} </syntaxhighlight>

Eine explizite Konfiguration könnte folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<User>()
.HasOne(u => u.Profile)
.WithOne(p => p.User)
.HasForeignKey<UserProfile>(p => p.UserId);
</syntaxhighlight>

== n:m-Beziehung ==

Ein Produkt kann mehreren Kategorien zugeordnet sein. Gleichzeitig kann eine Kategorie mehrere Produkte enthalten.

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Category> Categories { get; set; }
= new List<Category>();
```

} </syntaxhighlight>

<syntaxhighlight lang="csharp">
public class Category
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public ICollection<Product> Products { get; set; }
= new List<Product>();
```

} </syntaxhighlight>

EF Core kann für eine einfache n:m-Beziehung automatisch eine Zwischentabelle verwalten.

Wenn die Beziehung selbst zusätzliche Eigenschaften besitzt, sollte dagegen eine eigene Entity verwendet werden.

Beispiel:

<pre>
Product
│
│ 1:n
▼
ProductCategory
▲
│ n:1
│
Category
</pre>

== Laden zusammengehöriger Daten ==

EF Core bietet unterschiedliche Möglichkeiten, Navigation Properties zu laden.

{| class="wikitable" style="margin:auto"

| + Strategien zum Laden von Beziehungen | | |
| -------------------------------------- | - | ------------------------------------------------------------------ |
| ! Strategie !! Beschreibung | | |
| - | | |
| Eager Loading | | zusammengehörige Daten werden sofort mitgeladen |
| - | | |
| Explicit Loading | | zusammengehörige Daten werden gezielt nachgeladen |
| - | | |
| Lazy Loading | | Daten werden erst beim Zugriff auf die Navigation Property geladen |
| } | | |

== Eager Loading ==

Beim '''Eager Loading''' werden Beziehungen direkt mit der ursprünglichen Abfrage geladen.

Dies erfolgt mit <code>Include()</code>:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Mehrere Ebenen können mit <code>ThenInclude()</code> geladen werden:

<syntaxhighlight lang="csharp">
var orders = await context.Orders
.Include(o => o.Positions)
.ThenInclude(p => p.Product)
.ToListAsync();
</syntaxhighlight>

== Explicit Loading ==

Beim '''Explicit Loading''' werden Beziehungen gezielt nachgeladen.

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.FindAsync(1);

if (customer != null)
{
await context.Entry(customer)
.Collection(c => c.Orders)
.LoadAsync();
} </syntaxhighlight>

== Lazy Loading ==

Beim '''Lazy Loading''' werden Navigation Properties automatisch geladen, sobald auf sie zugegriffen wird.

Dies kann bequem sein, birgt jedoch die Gefahr einer großen Zahl unbemerkter Datenbankabfragen.

Insbesondere kann dadurch das sogenannte '''N+1-Problem''' entstehen.

Lazy Loading sollte deshalb bewusst und nicht automatisch als Standardlösung eingesetzt werden.

== N+1-Problem ==

Angenommen, zunächst werden 100 Kunden geladen.

Anschließend wird für jeden Kunden einzeln dessen Bestellliste geladen.

Dann können beispielsweise folgende Datenbankzugriffe entstehen:

<pre>
1 Abfrage für die Kunden
+
100 Abfragen für die Bestellungen
=
101 Datenbankabfragen
</pre>

Bei großen Datenmengen kann dies erhebliche Performanceprobleme verursachen.

Eine mögliche Lösung ist Eager Loading:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.ToListAsync();
</syntaxhighlight>

Alternativ kann eine gezielte Projektion verwendet werden.

== Migrationen ==

'''Migrations''' ermöglichen die kontrollierte Weiterentwicklung eines Datenbankschemas zusammen mit dem C#-Datenmodell.

Angenommen, die Entity <code>Product</code> wird um eine Property ergänzt:

<syntaxhighlight lang="csharp">
public string Description { get; set; } = string.Empty;
</syntaxhighlight>

Anschließend kann eine Migration erstellt werden:

<syntaxhighlight lang="text">
dotnet ef migrations add AddProductDescription
</syntaxhighlight>

EF Core erstellt daraus eine Migrationsklasse.

Vereinfacht kann diese beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<string>(
name: "Description",
table: "Products",
type: "nvarchar(max)",
nullable: false,
defaultValue: "");
}

protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "Description",
table: "Products");
} </syntaxhighlight>

Die Migration kann anschließend auf die Datenbank angewendet werden:

<syntaxhighlight lang="text">
dotnet ef database update
</syntaxhighlight>

== Wichtige Migrationsbefehle ==

{| class="wikitable" style="margin:auto"

| + Wichtige Befehle für EF-Core-Migrationen | | |
| ------------------------------------------ | - | ------------------------------------------------- |
| ! Befehl !! Funktion | | |
| - | | |
| dotnet ef migrations add Name | | neue Migration erzeugen |
| - | | |
| dotnet ef migrations list | | vorhandene Migrationen anzeigen |
| - | | |
| dotnet ef migrations remove | | letzte Migration entfernen |
| - | | |
| dotnet ef database update | | Datenbank auf die neueste Migration aktualisieren |
| - | | |
| dotnet ef database update MigrationName | | Datenbank auf eine bestimmte Migration setzen |
| - | | |
| dotnet ef migrations script | | SQL-Skript für Migrationen erzeugen |
| } | | |

== Migrationen in Produktivsystemen ==

Migrationen sollten in Produktivumgebungen kontrolliert eingesetzt werden.

Das automatische Ausführen aller Migrationen beim Programmstart ist zwar technisch möglich, für geschäftskritische Systeme jedoch nicht zwangsläufig die beste Lösung.

Ein kontrollierter Deployment-Prozess ermöglicht unter anderem:

* Prüfung der Datenbankänderungen vor dem Deployment
* Erstellung und Archivierung von SQL-Skripten
* Durchführung eines Backups vor einer Migration
* Planung länger laufender Änderungen
* kontrollierte Vergabe von Datenbankberechtigungen
* einfachere Fehleranalyse

Ein SQL-Skript für vorhandene Migrationen kann beispielsweise erzeugt werden:

<syntaxhighlight lang="text">
dotnet ef migrations script
</syntaxhighlight>

== Code First ==

Beim '''Code-First-Ansatz''' wird zunächst das Datenmodell in C# erstellt.

Aus diesem Modell wird anschließend das Datenbankschema erzeugt.

<pre>
C#-Entity-Klassen
│
▼
EF-Core-Modell
│
▼
Migration
│
▼
Datenbankschema
</pre>

Vorteile von Code First:

* Datenmodell befindet sich im Quellcode
* Datenmodell kann mit Git versioniert werden
* Migrationen dokumentieren Schemaänderungen
* gute Integration in CI/CD-Prozesse
* Datenbank und Anwendung können gemeinsam weiterentwickelt werden

== Database First ==

Beim '''Database-First-Ansatz''' existiert die Datenbank bereits.

EF Core kann daraus C#-Klassen und einen DbContext erzeugen.

Dieser Vorgang wird als '''Reverse Engineering''' beziehungsweise '''Scaffolding''' bezeichnet.

Beispiel:

<syntaxhighlight lang="text">
dotnet ef dbcontext scaffold "CONNECTION_STRING" Microsoft.EntityFrameworkCore.SqlServer
</syntaxhighlight>

Database First ist insbesondere bei bestehenden beziehungsweise älteren Datenbanken interessant.

Beispielsweise kann es bei der Modernisierung einer Legacy-Anwendung sinnvoll sein, eine bestehende Datenbank zunächst unverändert weiterzuverwenden.

== Code First und Database First im Vergleich ==

{| class="wikitable" style="margin:auto"

| + Vergleich von Code First und Database First | | | | |
| --------------------------------------------- | - | ---------------------------- | - | --------------------------- |
| ! Eigenschaft !! Code First !! Database First | | | | |
| - | | | | |
| Ausgangspunkt | | C#-Modell | | vorhandene Datenbank |
| - | | | | |
| Schemaerstellung | | über EF Core und Migrationen | | Datenbank existiert bereits |
| - | | | | |
| Geeignet für neue Anwendungen | | sehr gut | | eingeschränkt |
| - | | | | |
| Geeignet für Legacy-Datenbanken | | möglich | | sehr gut |
| - | | | | |
| Schemaänderungen | | häufig über Migrationen | | häufig datenbankseitig |
| } | | | | |

== SaveChanges ==

Mit:

<syntaxhighlight lang="csharp">
context.SaveChanges();
</syntaxhighlight>

beziehungsweise:

<syntaxhighlight lang="csharp">
await context.SaveChangesAsync();
</syntaxhighlight>

werden die vom Change Tracker registrierten Änderungen in die Datenbank geschrieben.

Vereinfacht ergibt sich folgende Zuordnung:

{| class="wikitable" style="margin:auto"

| + Zusammenhang zwischen Entity State und Datenbankoperation | | |
| ----------------------------------------------------------- | - | -------------- |
| ! Entity State !! Typische Datenbankoperation | | |
| - | | |
| Added | | INSERT |
| - | | |
| Modified | | UPDATE |
| - | | |
| Deleted | | DELETE |
| - | | |
| Unchanged | | keine Änderung |
| } | | |

== Transaktionen ==

EF Core verwendet für einen einzelnen <code>SaveChanges()</code>-Aufruf normalerweise eine Transaktion, sofern der verwendete Provider Transaktionen unterstützt.

Für komplexere Abläufe können Transaktionen explizit verwaltet werden.

Beispiel:

<syntaxhighlight lang="csharp">
await using var transaction =
await context.Database.BeginTransactionAsync();

try
{
var customer = new Customer
{
Name = "Max Mustermann"
};

```
context.Customers.Add(customer);

await context.SaveChangesAsync();

var order = new Order
{
CustomerId = customer.Id,
OrderDate = DateTime.UtcNow
};

context.Orders.Add(order);

await context.SaveChangesAsync();

await transaction.CommitAsync();
```

}
catch
{
await transaction.RollbackAsync();

```
throw;
```

} </syntaxhighlight>

Dadurch wird sichergestellt, dass zusammengehörige Änderungen als Einheit behandelt werden.

== Optimistic Concurrency ==

Mehrere Benutzer oder Prozesse können gleichzeitig denselben Datensatz bearbeiten.

Beispiel:

<pre>
Benutzer A liest Datensatz
│
Benutzer B liest Datensatz
│
Benutzer A verändert und speichert Datensatz
│
Benutzer B verändert und speichert Datensatz
</pre>

Ohne zusätzliche Kontrolle könnte Benutzer B die Änderung von Benutzer A überschreiben.

EF Core unterstützt deshalb '''Optimistic Concurrency'''.

Bei SQL Server kann beispielsweise eine RowVersion verwendet werden:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public byte[] RowVersion { get; set; } = Array.Empty<byte>();
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.Property(p => p.RowVersion)
.IsRowVersion();
</syntaxhighlight>

Wurde der Datensatz zwischen Lesen und Schreiben durch einen anderen Prozess verändert, kann EF Core eine:

<syntaxhighlight lang="text">
DbUpdateConcurrencyException
</syntaxhighlight>

auslösen.

Die Anwendung muss anschließend entscheiden, wie dieser Konflikt behandelt werden soll.

== ExecuteUpdate und ExecuteDelete ==

Bei Massenänderungen ist es häufig unnötig, alle betroffenen Entities zunächst in den Arbeitsspeicher zu laden.

Eine klassische Vorgehensweise wäre:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price < 100)
.ToListAsync();

foreach (var product in products)
{
product.Price *= 1.05m;
}

await context.SaveChangesAsync(); </syntaxhighlight>

Stattdessen kann <code>ExecuteUpdateAsync()</code> verwendet werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Price < 100)
.ExecuteUpdateAsync(setters => setters
.SetProperty(
p => p.Price,
p => p.Price * 1.05m));
</syntaxhighlight>

Mehrere Datensätze können direkt gelöscht werden:

<syntaxhighlight lang="csharp">
await context.Products
.Where(p => p.Stock <= 0)
.ExecuteDeleteAsync();
</syntaxhighlight>

Diese Verfahren vermeiden das vorherige Laden sämtlicher betroffener Entities.

== Raw SQL ==

EF Core ermöglicht zusätzlich die Ausführung von SQL.

Beispielsweise:

<syntaxhighlight lang="csharp">
var products = await context.Products
.FromSqlInterpolated(
$"SELECT * FROM Products WHERE Price > {minimumPrice}")
.ToListAsync();
</syntaxhighlight>

Bei SQL-Abfragen müssen immer parameterisierte Verfahren verwendet werden.

Unsicher wäre beispielsweise:

<syntaxhighlight lang="csharp">
var sql =
"SELECT * FROM Products WHERE Name = '" +
userInput +
"'";
</syntaxhighlight>

Dies kann zu '''SQL-Injection-Schwachstellen''' führen.

== Globale Query Filter ==

Mit einem '''Global Query Filter''' kann eine Bedingung definiert werden, die automatisch auf Abfragen einer Entity angewendet wird.

Ein typisches Beispiel ist '''Soft Delete'''.

Entity:

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public bool IsDeleted { get; set; }
```

} </syntaxhighlight>

Konfiguration:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasQueryFilter(p => !p.IsDeleted);
</syntaxhighlight>

Eine normale Abfrage:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

liefert dadurch standardmäßig nur nicht gelöschte Produkte.

Der Filter kann bei Bedarf ignoriert werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.IgnoreQueryFilters()
.ToListAsync();
</syntaxhighlight>

Weitere Einsatzmöglichkeiten globaler Filter sind beispielsweise:

* Multi-Tenant-Anwendungen
* Mandantenfilter
* Archivierung
* zeitabhängige Datensichten

== Indizes ==

Datenbankindizes können über EF Core konfiguriert werden.

Beispiel:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Product>()
.HasIndex(p => p.Name);
</syntaxhighlight>

Ein eindeutiger Index:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Customer>()
.HasIndex(c => c.Email)
.IsUnique();
</syntaxhighlight>

Indizes können Leseoperationen erheblich beschleunigen.

Sie haben jedoch auch Nachteile:

* zusätzlicher Speicherverbrauch
* zusätzlicher Aufwand bei INSERT
* zusätzlicher Aufwand bei UPDATE
* zusätzlicher Aufwand bei DELETE

Die Auswahl sinnvoller Indizes gehört deshalb weiterhin zum Datenbankdesign.

== Value Conversions ==

Mit '''Value Conversions''' können .NET-Werte beim Speichern in einen anderen Datenbankwert umgewandelt werden.

Ein Enum kann beispielsweise als String gespeichert werden:

<syntaxhighlight lang="csharp">
modelBuilder.Entity<Order>()
.Property(o => o.Status)
.HasConversion<string>();
</syntaxhighlight>

Statt:

<pre>
0
1
2
</pre>

könnten dann beispielsweise folgende Werte gespeichert werden:

<pre>
New
Processing
Completed
</pre>

== Complex Types ==

EF Core unterstützt komplexe Typen zur Abbildung strukturierter Werte.

Beispiel:

<syntaxhighlight lang="csharp">
public class Address
{
public string Street { get; set; } = string.Empty;

```
public string City { get; set; } = string.Empty;

public string PostalCode { get; set; } = string.Empty;
```

} </syntaxhighlight>

Eine Entity kann diesen Typ verwenden:

<syntaxhighlight lang="csharp">
public class Customer
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public Address Address { get; set; } = new();
```

} </syntaxhighlight>

Geeignete Einsatzbereiche sind beispielsweise:

* Adressen
* Kontaktdaten
* Koordinaten
* Geldwerte
* wiederverwendbare Value Objects

== Paging ==

Große Datenmengen sollten normalerweise nicht vollständig auf einmal geladen werden.

Ein einfaches Paging kann mit <code>Skip()</code> und <code>Take()</code> umgesetzt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.OrderBy(p => p.Id)
.Skip(100)
.Take(50)
.ToListAsync();
</syntaxhighlight>

Damit werden 50 Datensätze ab Position 101 geladen.

Für sehr große Datenbestände kann sogenanntes '''Keyset Paging''' beziehungsweise '''Cursor Paging''' effizienter sein.

== Split Queries ==

Bei komplexen Abfragen mit mehreren Includes kann eine einzelne SQL-Abfrage sehr große Ergebnismengen erzeugen.

EF Core unterstützt deshalb '''Split Queries'''.

Beispiel:

<syntaxhighlight lang="csharp">
var customers = await context.Customers
.Include(c => c.Orders)
.AsSplitQuery()
.ToListAsync();
</syntaxhighlight>

Dabei erzeugt EF Core mehrere SQL-Abfragen.

Ob Single Query oder Split Query effizienter ist, hängt vom jeweiligen Datenmodell und der Datenmenge ab.

== Erzeugtes SQL anzeigen ==

Bei der Analyse komplexer Abfragen ist es häufig sinnvoll, das von EF Core erzeugte SQL zu betrachten.

Eine LINQ-Abfrage kann beispielsweise zunächst gespeichert werden:

<syntaxhighlight lang="csharp">
var query = context.Products
.Where(p => p.Price > 100);
</syntaxhighlight>

Das zugehörige SQL kann anschließend ausgegeben werden:

<syntaxhighlight lang="csharp">
var sql = query.ToQueryString();
</syntaxhighlight>

Dies ist besonders hilfreich für:

* Performanceanalysen
* Fehlersuche
* Prüfung von JOINs
* Prüfung von Filtern
* Analyse komplexer LINQ-Abfragen

== Logging ==

EF Core integriert sich in das Logging-System von .NET.

Eine einfache Konsolenausgabe kann beispielsweise aktiviert werden:

<syntaxhighlight lang="csharp">
options
.UseSqlServer(connectionString)
.LogTo(Console.WriteLine);
</syntaxhighlight>

Damit können unter anderem folgende Informationen sichtbar gemacht werden:

* ausgeführte SQL-Befehle
* Dauer von Datenbankoperationen
* EF-Core-Warnungen
* Fehler
* Verbindungsinformationen
* Transaktionen

Sensible Daten sollten in Produktivsystemen nicht unkontrolliert protokolliert werden.

== Performance ==

Die Abstraktion von EF Core erleichtert die Entwicklung, kann jedoch dazu führen, dass teure Datenbankoperationen im C#-Code zunächst unscheinbar wirken.

Bei Performanceproblemen sollten insbesondere folgende Punkte untersucht werden:

* Anzahl der Datenbankabfragen
* erzeugtes SQL
* verwendete Indizes
* Datenmenge
* Change Tracking
* Include-Aufrufe
* große Objektgraphen
* N+1-Probleme
* unnötige Datenbank-Roundtrips
* Paging
* Projektionen
* Datenbankausführungspläne

== Nur benötigte Daten laden ==

Wenn lediglich die Namen von Produkten benötigt werden, sollte nicht die vollständige Entity geladen werden.

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

Anschließend:

<syntaxhighlight lang="csharp">
var names = products
.Select(p => p.Name)
.ToList();
</syntaxhighlight>

Besser:

<syntaxhighlight lang="csharp">
var names = await context.Products
.Select(p => p.Name)
.ToListAsync();
</syntaxhighlight>

Dadurch können Datenmenge und Speicherbedarf reduziert werden.

== DbContext-Lebensdauer ==

Ein DbContext ist als '''kurzlebige Unit of Work''' gedacht.

Ein typischer Ablauf sieht folgendermaßen aus:

<pre>
DbContext erzeugen
│
▼
Daten laden
│
▼
Änderungen durchführen
│
▼
SaveChanges
│
▼
DbContext freigeben
</pre>

Ein DbContext sollte normalerweise nicht:

* global gespeichert werden
* als Singleton verwendet werden
* über sehr lange Zeiträume existieren
* gleichzeitig von mehreren Threads verwendet werden

'''DbContext ist nicht threadsicher.'''

== DbContextFactory ==

In einigen Anwendungstypen ist es sinnvoll, DbContext-Instanzen über eine Factory zu erzeugen.

Dies gilt beispielsweise für:

* Blazor
* Desktop-Anwendungen
* Background Services
* Worker Services
* parallele Verarbeitung

Registrierung:

<syntaxhighlight lang="csharp">
builder.Services.AddDbContextFactory<ApplicationDbContext>(
options =>
options.UseSqlServer(connectionString));
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="csharp">
await using var context =
await dbContextFactory.CreateDbContextAsync();
</syntaxhighlight>

== EF Core in Blazor ==

Bei serverseitigen Blazor-Anwendungen muss besonders auf die Lebensdauer eines DbContext geachtet werden.

Ein klassischer ASP.NET-Core-Request existiert nur relativ kurz.

Ein Blazor-Circuit kann dagegen deutlich länger bestehen.

Daher kann die Verwendung von:

<syntaxhighlight lang="csharp">
IDbContextFactory<ApplicationDbContext>
</syntaxhighlight>

sinnvoll sein.

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductService
{
private readonly IDbContextFactory<ApplicationDbContext>
_contextFactory;

```
public ProductService(
IDbContextFactory<ApplicationDbContext> contextFactory)
{
_contextFactory = contextFactory;
}

public async Task<List<Product>> GetProductsAsync()
{
await using var context =
await _contextFactory.CreateDbContextAsync();

return await context.Products
.AsNoTracking()
.ToListAsync();
}
```

} </syntaxhighlight>

Dadurch kann für einen Vorgang eine eigene DbContext-Instanz verwendet werden.

Dies reduziert unter anderem Probleme durch:

* lange Tracking-Zeiträume
* parallele Datenbankoperationen
* veraltete Entity-Zustände
* unnötigen Speicherverbrauch

== Repository Pattern ==

EF Core wird häufig zusammen mit dem '''Repository Pattern''' eingesetzt.

Eine Schnittstelle könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public interface IProductRepository
{
Task<Product?> GetByIdAsync(int id);

```
Task<List<Product>> GetAllAsync();

Task AddAsync(Product product);
```

} </syntaxhighlight>

Eine Implementierung:

<syntaxhighlight lang="csharp">
public class ProductRepository : IProductRepository
{
private readonly ApplicationDbContext _context;

```
public ProductRepository(
ApplicationDbContext context)
{
_context = context;
}

public async Task<Product?> GetByIdAsync(int id)
{
return await _context.Products.FindAsync(id);
}

public async Task<List<Product>> GetAllAsync()
{
return await _context.Products
.AsNoTracking()
.ToListAsync();
}

public async Task AddAsync(Product product)
{
_context.Products.Add(product);

await _context.SaveChangesAsync();
}
```

} </syntaxhighlight>

EF Core selbst implementiert bereits viele Eigenschaften des Repository- und Unit-of-Work-Patterns.

{| class="wikitable" style="margin:auto"

| + Zuordnung von EF-Core-Komponenten zu bekannten Patterns | | |
| --------------------------------------------------------- | - | ------------ |
| ! EF-Core-Komponente !! Ähnliches Entwurfsmuster | | |
| - | | |
| DbSet | | Repository |
| - | | |
| DbContext | | Unit of Work |
| } | | |

Eine zusätzliche Repository-Schicht sollte deshalb einen konkreten architektonischen Nutzen besitzen.

Ein Repository, das lediglich:

<pre>
GetAll()
GetById()
Add()
Update()
Delete()
</pre>

um ein DbSet herum implementiert, erzeugt möglicherweise nur eine zusätzliche Abstraktionsschicht ohne echten Mehrwert.

== DTOs und Entities ==

Datenbank-Entities sollten insbesondere in Webanwendungen nicht automatisch gleichzeitig als API-Datenmodelle verwendet werden.

Häufig ist eine Trennung sinnvoll zwischen:

* Entity
* DTO
* ViewModel
* Request Model
* Response Model

Beispiel:

<syntaxhighlight lang="csharp">
public class ProductDto
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }
```

} </syntaxhighlight>

Dadurch wird verhindert, dass interne Datenbankstrukturen automatisch Bestandteil einer öffentlichen Schnittstelle werden.

== Sicherheit ==

EF Core parametrisiert normale LINQ-Abfragen automatisch.

Beispiel:

<syntaxhighlight lang="csharp">
var customer = await context.Customers
.Where(c => c.Name == userInput)
.FirstOrDefaultAsync();
</syntaxhighlight>

EF Core verwendet für <code>userInput</code> normalerweise einen Datenbankparameter.

Dies reduziert das Risiko von SQL Injection erheblich.

Trotzdem müssen weitere Sicherheitsmaßnahmen beachtet werden:

* Connection Strings nicht im Quellcode speichern
* Zugangsdaten über Secret Stores oder sichere Konfiguration verwalten
* Least-Privilege-Prinzip für Datenbankkonten verwenden
* Raw SQL ausschließlich parameterisiert ausführen
* Benutzereingaben validieren
* Fehlerdetails nicht ungefiltert an Clients ausgeben
* sensible Daten nicht unkontrolliert protokollieren
* produktive Zugangsdaten nicht in Git speichern

== Testing ==

EF-Core-Code kann auf verschiedene Arten getestet werden.

{| class="wikitable" style="margin:auto"

| + Möglichkeiten zum Testen von EF-Core-Anwendungen | | |
| -------------------------------------------------- | - | ---------------------------------------------------------------------- |
| ! Verfahren !! Eigenschaften | | |
| - | | |
| echte Testdatenbank | | sehr realitätsnah |
| - | | |
| temporäre Datenbank | | gut für automatisierte Integrationstests |
| - | | |
| SQLite In-Memory | | relationale Datenbank im Arbeitsspeicher |
| - | | |
| EF-Core-InMemory-Provider | | schnell, aber kein vollständiger Ersatz für eine relationale Datenbank |
| - | | |
| Testcontainer | | echtes Datenbanksystem innerhalb eines Containers |
| } | | |

== InMemory Provider ==

EF Core besitzt einen eigenen InMemory-Provider.

Dieser kann für einfache Tests hilfreich sein.

Er verhält sich allerdings nicht vollständig wie eine relationale Datenbank.

Unterschiede bestehen unter anderem bei:

* SQL-Übersetzung
* relationalen Constraints
* Transaktionen
* Datenbankfunktionen
* providerabhängigem Verhalten

Ein Test, der mit dem InMemory-Provider erfolgreich ist, muss deshalb nicht zwangsläufig mit SQL Server, PostgreSQL oder MariaDB funktionieren.

== SQLite In-Memory ==

Für relationale Tests kann SQLite im Arbeitsspeicher eine bessere Annäherung sein.

Auch SQLite verhält sich jedoch nicht vollständig identisch zu anderen Datenbanksystemen.

Wenn providerabhängiges Verhalten getestet werden soll, ist eine Testinstanz des tatsächlich eingesetzten Datenbanksystems zuverlässiger.

== Integrationstests mit Containern ==

Für komplexe Anwendungen können Datenbanken während eines Tests temporär als Container gestartet werden.

Beispielsweise:

<pre>
Integrationstest
│
▼
Docker / Testcontainer
│
▼
temporärer SQL Server
oder PostgreSQL
│
▼
EF Core
</pre>

Dadurch können Tests gegen ein echtes Datenbanksystem ausgeführt werden.

== Interceptors ==

EF Core unterstützt '''Interceptors''', mit denen Datenbankoperationen abgefangen oder erweitert werden können.

Einsatzmöglichkeiten sind beispielsweise:

* Logging
* Auditing
* Performance-Messungen
* Analyse von SQL-Befehlen
* Überwachung von SaveChanges
* automatische Ergänzung bestimmter Werte

Ein Beispiel ist:

<syntaxhighlight lang="text">
SaveChangesInterceptor
</syntaxhighlight>

Dieser kann vor oder nach einem SaveChanges-Vorgang eigenen Code ausführen.

== Auditing ==

Viele Geschäftsanwendungen müssen speichern, wann ein Datensatz erzeugt oder verändert wurde.

Eine gemeinsame Basisklasse könnte beispielsweise folgendermaßen aussehen:

<syntaxhighlight lang="csharp">
public abstract class EntityBase
{
public DateTime CreatedAt { get; set; }

```
public DateTime? ModifiedAt { get; set; }
```

} </syntaxhighlight>

Weitere mögliche Auditfelder sind:

* CreatedBy
* CreatedAt
* ModifiedBy
* ModifiedAt
* DeletedBy
* DeletedAt

Diese Werte können beispielsweise innerhalb von SaveChanges oder über einen Interceptor automatisch gepflegt werden.

== Soft Delete ==

Beim '''Soft Delete''' wird ein Datensatz nicht physisch aus der Datenbank gelöscht.

Stattdessen kann beispielsweise eine Property verwendet werden:

<syntaxhighlight lang="csharp">
public bool IsDeleted { get; set; }
</syntaxhighlight>

Beim Löschen wird dann:

<syntaxhighlight lang="csharp">
product.IsDeleted = true;
</syntaxhighlight>

gesetzt.

{| class="wikitable" style="margin:auto"

| + Vor- und Nachteile von Soft Delete | | |
| ------------------------------------- | - | ------------------------------------------------------ |
| ! Vorteile !! Nachteile | | |
| - | | |
| Daten können wiederhergestellt werden | | Datenbank wächst dauerhaft weiter |
| - | | |
| Historie bleibt erhalten | | Abfragen müssen gelöschte Datensätze berücksichtigen |
| - | | |
| Beziehungen bleiben nachvollziehbar | | Unique Constraints können komplizierter werden |
| - | | |
| Auditing wird erleichtert | | Datenschutz kann trotzdem physische Löschung erfordern |
| } | | |

Soft Delete wird häufig mit Global Query Filters kombiniert.

== Typische Performancefehler ==

=== Komplette Tabellen laden ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products = await context.Products
.ToListAsync();
</syntaxhighlight>

und anschließend im Arbeitsspeicher filtern.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== ToList zu früh aufrufen ===

Ungünstig:

<syntaxhighlight lang="csharp">
var products =
(await context.Products.ToListAsync())
.Where(p => p.Price > 100);
</syntaxhighlight>

Hier werden zunächst sämtliche Produkte übertragen.

Besser:

<syntaxhighlight lang="csharp">
var products = await context.Products
.Where(p => p.Price > 100)
.ToListAsync();
</syntaxhighlight>

=== Tracking bei Read-Only-Abfragen ===

Wenn Daten ausschließlich angezeigt werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Zu viele Includes ===

Eine große Zahl von <code>Include()</code>-Aufrufen kann zu sehr großen SQL-Abfragen und Ergebnismengen führen.

Eine gezielte Projektion kann effizienter sein.

=== N+1-Abfragen ===

Viele kleine Datenbankabfragen können erheblich langsamer sein als eine oder wenige gezielt formulierte Abfragen.

=== Fehlende Indizes ===

Auch eine gut formulierte EF-Core-Abfrage kann langsam sein, wenn wichtige Datenbankindizes fehlen.

== Häufige Fehler und Probleme ==

{| class="wikitable" style="margin:auto"

| + Häufige EF-Core-Probleme | | |
| ---------------------------------------------- | - | --------------------------------------------------------------------------- |
| ! Problem !! Typische Ursache | | |
| - | | |
| DbContext wurde bereits disposed | | DbContext wird außerhalb seiner vorgesehenen Lebensdauer verwendet |
| - | | |
| A second operation was started on this context | | mehrere parallele Operationen verwenden denselben DbContext |
| - | | |
| Entity wird bereits getrackt | | mehrere Instanzen mit gleichem Primärschlüssel werden gleichzeitig verfolgt |
| - | | |
| LINQ-Ausdruck kann nicht übersetzt werden | | verwendeter C#-Ausdruck besitzt keine SQL-Übersetzung |
| - | | |
| Migration passt nicht zur Datenbank | | Schema und Migrationshistorie sind nicht synchron |
| } | | |

== EF Core gegenüber ADO.NET ==

ADO.NET arbeitet wesentlich näher an der Datenbank.

Bei ADO.NET müssen Entwickler häufig selbst:

* SQL schreiben
* Connection verwalten
* Commands erstellen
* Parameter definieren
* DataReader verarbeiten
* Datensätze auf Objekte abbilden

EF Core übernimmt einen großen Teil dieser Aufgaben.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und ADO.NET | | | | |
| ------------------------------------------------------ | - | ------------------ | - | ----------------------------- |
| ! Eigenschaft !! EF Core !! ADO.NET | | | | |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Abfragesprache | | hauptsächlich LINQ | | hauptsächlich SQL |
| - | | | | |
| Objekt-Mapping | | automatisch | | normalerweise manuell |
| - | | | | |
| Change Tracking | | integriert | | normalerweise manuell |
| - | | | | |
| Migrationen | | integriert | | nicht Bestandteil von ADO.NET |
| - | | | | |
| Kontrolle über SQL | | geringer | | sehr hoch |
| - | | | | |
| Entwicklungsaufwand | | häufig geringer | | häufig höher |
| } | | | | |

== EF Core gegenüber Dapper ==

'''Dapper''' ist ein sogenannter '''Micro-ORM'''.

Dapper konzentriert sich stärker auf das Mapping von SQL-Ergebnissen auf .NET-Objekte.

{| class="wikitable" style="margin:auto"

| + Vergleich zwischen Entity Framework Core und Dapper | | | | |
| ----------------------------------------------------- | - | -------------------------- | - | ---------------------- |
| ! Eigenschaft !! EF Core !! Dapper | | | | |
| - | | | | |
| LINQ-Abfragen | | Ja | | normalerweise Nein |
| - | | | | |
| automatische SQL-Erzeugung | | Ja | | überwiegend Nein |
| - | | | | |
| Change Tracking | | Ja | | Nein |
| - | | | | |
| Migrationen | | Ja | | Nein |
| - | | | | |
| Beziehungen | | umfangreiche Unterstützung | | weitgehend manuell |
| - | | | | |
| Abstraktionsgrad | | hoch | | niedrig |
| - | | | | |
| Kontrolle über SQL | | mittel bis hoch | | sehr hoch |
| - | | | | |
| CRUD-Entwicklung | | sehr komfortabel | | stärker SQL-orientiert |
| } | | | | |

Beide Technologien können innerhalb derselben Anwendung eingesetzt werden.

Ein mögliches Szenario wäre:

* EF Core für normale CRUD-Funktionen
* Dapper für einzelne hochoptimierte Spezialabfragen

== EF Core ersetzt kein Datenbankwissen ==

Auch bei der Verwendung eines ORM bleiben Kenntnisse relationaler Datenbanken wichtig.

Entwickler sollten insbesondere folgende Konzepte verstehen:

* Primärschlüssel
* Fremdschlüssel
* Joins
* Normalisierung
* Constraints
* Indizes
* Transaktionen
* Isolation Levels
* Deadlocks
* Query-Pläne
* SQL-Datentypen
* Datenbankperformance

EF Core kann ein schlechtes Datenmodell nicht automatisch in ein gutes Datenmodell umwandeln.

== EF Core ersetzt keine SQL-Kenntnisse ==

Für einfache Anwendungen ist es möglich, einen großen Teil der Datenbankzugriffe ausschließlich mit LINQ umzusetzen.

Bei komplexeren Anwendungen sind SQL-Kenntnisse dennoch wichtig.

Sie helfen beispielsweise bei:

* Analyse des erzeugten SQL
* Performanceoptimierung
* Planung von Indizes
* Analyse von JOINs
* Verständnis von Ausführungsplänen
* Entwicklung komplexer Reports
* Fehleranalyse
* Datenbankmigrationen

Die Kombination aus guten EF-Core- und SQL-Kenntnissen ist deshalb besonders wertvoll.

== Vorteile von Entity Framework Core ==

Zu den wichtigsten Vorteilen gehören:

* hoher Abstraktionsgrad
* LINQ-Unterstützung
* starke Typisierung
* automatische Abbildung zwischen Objekten und Datenbank
* integriertes Change Tracking
* Migrationen
* Unterstützung verschiedener Datenbanksysteme
* Integration in ASP.NET Core
* asynchrone Datenbankoperationen
* umfangreiche Konfigurationsmöglichkeiten
* integrierte Behandlung von Beziehungen
* gute Unterstützung moderner .NET-Anwendungen
* automatische Parameterisierung vieler Datenbankabfragen
* hohe Entwicklungsgeschwindigkeit

== Nachteile von Entity Framework Core ==

EF Core besitzt auch einige Nachteile beziehungsweise Risiken:

* zusätzliche Abstraktionsschicht
* erzeugtes SQL ist nicht unmittelbar sichtbar
* ungeschickte LINQ-Abfragen können ineffizientes SQL erzeugen
* komplexe Abfragen können schwer nachvollziehbar sein
* Change Tracking benötigt zusätzliche Ressourcen
* providerabhängiges Verhalten
* Migrationen müssen sorgfältig verwaltet werden
* komplexe Spezialabfragen können Raw SQL erfordern
* Entwickler können Performanceprobleme verursachen, ohne dies im C#-Code sofort zu erkennen

== Best Practices ==

=== DbContext kurzlebig halten ===

Ein DbContext sollte eine klar begrenzte Arbeitseinheit repräsentieren.

=== Asynchrone APIs verwenden ===

In Web- und Serveranwendungen sollten normalerweise Methoden wie:

<syntaxhighlight lang="csharp">
ToListAsync()
</syntaxhighlight>

und:

<syntaxhighlight lang="csharp">
SaveChangesAsync()
</syntaxhighlight>

verwendet werden.

=== AsNoTracking bei reinen Leseabfragen ===

Wenn Entities nur gelesen werden:

<syntaxhighlight lang="csharp">
.AsNoTracking()
</syntaxhighlight>

verwenden.

=== Nur benötigte Daten auswählen ===

DTO-Projektionen reduzieren häufig Datenmenge und Speicherbedarf.

=== Migrationen versionieren ===

Migrationsdateien sollten normalerweise zusammen mit dem Quellcode in Git gespeichert werden.

=== Migrationen vor dem Deployment prüfen ===

Vor einer produktiven Migration sollte geprüft werden, welche Änderungen tatsächlich auf der Datenbank ausgeführt werden.

=== Connection Strings schützen ===

Produktive Zugangsdaten gehören nicht in das Git-Repository.

=== CancellationToken verwenden ===

In Webanwendungen können Abfragen mit einem CancellationToken ausgeführt werden:

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.ToListAsync(cancellationToken);
</syntaxhighlight>

=== Generiertes SQL prüfen ===

Komplexe LINQ-Abfragen sollten bei Bedarf mit <code>ToQueryString()</code> analysiert werden.

=== Datenbankindizes planen ===

EF Core ersetzt keine Datenbankoptimierung.

Häufig verwendete Filter-, Sortier- und Join-Spalten sollten hinsichtlich sinnvoller Indizes überprüft werden.

=== DbContext nicht parallel verwenden ===

Eine einzelne DbContext-Instanz darf nicht für mehrere parallele Datenbankoperationen verwendet werden.

=== Geschäftslogik vom DbContext trennen ===

Der DbContext sollte sich primär um Datenzugriff, Mapping und Persistenz kümmern.

Komplexe Geschäftsregeln gehören normalerweise in geeignete Domain- oder Service-Komponenten.

== Beispiel einer einfachen EF-Core-Anwendung ==

=== Entity ===

<syntaxhighlight lang="csharp">
public class Product
{
public int Id { get; set; }

```
public string Name { get; set; } = string.Empty;

public decimal Price { get; set; }

public decimal Stock { get; set; }
```

} </syntaxhighlight>

=== DbContext ===

<syntaxhighlight lang="csharp">
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}

```
public DbSet<Product> Products => Set<Product>();

protected override void OnModelCreating(
ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity =>
{
entity.HasKey(p => p.Id);

entity.Property(p => p.Name)
.IsRequired()
.HasMaxLength(200);

entity.Property(p => p.Price)
.HasPrecision(10, 2);

entity.Property(p => p.Stock)
.HasPrecision(12, 3);
});
}
```

} </syntaxhighlight>

=== Registrierung ===

<syntaxhighlight lang="csharp">
builder.Services.AddDbContext<ApplicationDbContext>(
options =>
options.UseSqlServer(
builder.Configuration
.GetConnectionString("DefaultConnection")));
</syntaxhighlight>

=== Produkt anlegen ===

<syntaxhighlight lang="csharp">
var product = new Product
{
Name = "Kalkammonsalpeter",
Price = 289.50m,
Stock = 12500
};

context.Products.Add(product);

await context.SaveChangesAsync(); </syntaxhighlight>

=== Produkte lesen ===

<syntaxhighlight lang="csharp">
var products = await context.Products
.AsNoTracking()
.OrderBy(p => p.Name)
.ToListAsync();
</syntaxhighlight>

=== Produkt ändern ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
product.Price = 295.00m;

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

=== Produkt löschen ===

<syntaxhighlight lang="csharp">
var product = await context.Products
.FindAsync(productId);

if (product != null)
{
context.Products.Remove(product);

```
await context.SaveChangesAsync();
```

} </syntaxhighlight>

== Mögliche Projektstruktur ==

Für eine größere Anwendung könnte beispielsweise folgende Struktur verwendet werden:

<pre>
MyApplication
│
├── Domain
│ ├── Entities
│ ├── ValueObjects
│ └── Enums
│
├── Application
│ ├── DTOs
│ ├── Interfaces
│ └── Services
│
├── Infrastructure
│ └── Persistence
│ ├── ApplicationDbContext.cs
│ │
│ ├── Configurations
│ │ ├── ProductConfiguration.cs
│ │ ├── CustomerConfiguration.cs
│ │ └── OrderConfiguration.cs
│ │
│ └── Migrations
│
└── Web
├── Components
├── Controllers
└── Program.cs
</pre>

Bei kleineren Projekten ist eine derart umfangreiche Trennung nicht zwingend erforderlich.

Die Architektur sollte sich an der tatsächlichen Komplexität der Anwendung orientieren.

== Aktuelle EF-Core-Versionen ==

Stand September 2026 ist '''EF Core 10''' die aktuelle stabile LTS-Version.

{| class="wikitable" style="margin:auto"

| + Aktuell relevante EF-Core-Versionen | | | | |
| --------------------------------------------- | - | ------- | - | --------------------- |
| ! EF-Core-Version !! Zielframework !! Support | | | | |
| - | | | | |
| EF Core 10 | | .NET 10 | | bis 10. November 2028 |
| - | | | | |
| EF Core 9 | | .NET 8 | | bis 10. November 2026 |
| - | | | | |
| EF Core 8 | | .NET 8 | | bis 10. November 2026 |
| } | | | | |

EF Core 10 benötigt das .NET-10-SDK zum Kompilieren und die .NET-10-Runtime zur Ausführung.

Bei einem Upgrade zwischen Hauptversionen sollten grundsätzlich die dokumentierten '''Breaking Changes''' überprüft werden.

Die verwendeten EF-Core-Pakete sollten außerdem möglichst dieselbe Hauptversion verwenden.

Beispiel:

<pre>
Microsoft.EntityFrameworkCore 10.x
Microsoft.EntityFrameworkCore.SqlServer 10.x
Microsoft.EntityFrameworkCore.Design 10.x
</pre>

Bei Drittanbieter-Providern muss zusätzlich geprüft werden, ob die jeweilige Version die verwendete EF-Core-Hauptversion unterstützt.

== Wann ist EF Core sinnvoll? ==

EF Core eignet sich besonders für:

* ASP.NET-Core-Webanwendungen
* REST-APIs
* Blazor-Anwendungen
* Desktop-Anwendungen mit relationaler Datenbank
* Worker Services
* Geschäftsanwendungen
* CRUD-lastige Systeme
* Anwendungen mit vielen Beziehungen zwischen Entities
* Anwendungen mit Code-First-Datenmodellen
* Systeme mit versionierten Datenbankmigrationen

== Wann ist EF Core möglicherweise nicht die beste Lösung? ==

Andere Datenzugriffstechnologien können sinnvoller sein, wenn:

* nur sehr wenige und einfache SQL-Abfragen benötigt werden
* vollständige Kontrolle über jedes SQL-Statement erforderlich ist
* extrem performancekritische Spezialabfragen dominieren
* eine ungewöhnliche Legacy-Datenbank verwendet wird
* Stored Procedures die gesamte Datenzugriffsschicht bestimmen
* keine objektorientierte Abbildung der Daten erforderlich ist

Es ist ebenfalls möglich, EF Core mit anderen Technologien wie ADO.NET oder Dapper zu kombinieren.

== Zusammenfassung ==

'''Entity Framework Core''' ist das zentrale ORM-Framework für moderne .NET-Anwendungen.

Das grundlegende Modell besteht aus:

<pre>
Entity
│
▼
DbSet
│
▼
DbContext
│
▼
Entity Framework Core
│
▼
Database Provider
│
▼
Datenbank
</pre>

Die wichtigsten Konzepte sind:

* '''Entities''' repräsentieren Datensätze.
* '''DbSet''' repräsentiert eine Menge von Entities.
* '''DbContext''' verwaltet Datenbankzugriffe und Änderungen.
* '''LINQ''' dient zur Formulierung von Abfragen.
* '''Change Tracking''' erkennt Veränderungen an Entities.
* '''SaveChanges''' überträgt Änderungen in die Datenbank.
* '''Migrationen''' verwalten Änderungen am Datenbankschema.
* '''Navigation Properties''' bilden Beziehungen zwischen Entities ab.
* '''Database Provider''' ermöglichen die Unterstützung verschiedener Datenbanksysteme.
* '''AsNoTracking''' kann Read-Only-Abfragen effizienter machen.
* '''Projektionen''' reduzieren unnötige Datenübertragungen.
* '''DbContext''' sollte kurzlebig und nicht parallel verwendet werden.
* Trotz ORM bleiben Kenntnisse über SQL und relationale Datenbanken wichtig.

EF Core bietet für viele Geschäftsanwendungen einen guten Kompromiss zwischen '''Entwicklungsgeschwindigkeit''', '''Typsicherheit''', '''Wartbarkeit''', '''Abstraktion''' und '''Kontrolle über den Datenbankzugriff'''.

== Siehe auch ==

* [[.NET]]
* [[ASP.NET Core]]
* [[Blazor]]
* [[C Sharp|C#]]
* [[LINQ]]
* [[SQL]]
* [[Object-Relational Mapping]]
* [[Dependency Injection]]
* [[Repository Pattern]]
* [[Unit of Work]]
* [[SQL Server]]
* [[SQLite]]
* [[PostgreSQL]]
* [[MariaDB]]
* [[Docker]]
* [[CI/CD]]
* [[NuGet]]

== Quellen und weiterführende Dokumentation ==

* Microsoft Learn – Entity Framework Core
* Microsoft Learn – EF Core Releases and Planning
* Microsoft Learn – EF Core Database Providers
* Microsoft Learn – EF Core Change Tracking
* Microsoft Learn – EF Core Relationships
* Microsoft Learn – EF Core Migrations
* Microsoft Learn – EF Core Performance
* Microsoft Learn – What's New in EF Core 10

[[Kategorie:.NET]]
[[Kategorie:C Sharp]]
[[Kategorie:Datenbank]]
[[Kategorie:Entity Framework]]
[[Kategorie:Object-Relational Mapping]]
[[Kategorie:Softwareentwicklung]]