Was sind DTOs in NestJS?

Question

Accepted Answer

Ein **DTO (Data Transfer Object)** ist eine Klasse, die die **Form der Daten** definiert, die an Ihre API gesendet oder von ihr empfangen werden — typischerweise die Struktur eines Request-Body. DTOs bieten Typsicherheit, dienen als klarer Vertrag für Endpoints und ermöglichen (mit Validierungsdekoratoren) automatische Eingabevalidierung.

## Einen DTO definieren

```ts
import { IsEmail, IsString, MinLength, IsOptional, IsInt, Min } from "class-validator";

export class CreateUserDto {
  @IsEmail()                    // must be a valid email
  email: string;

@IsString()
  @MinLength(8)                 // password at least 8 chars
  password: string;

@IsOptional()                 // optional field
  @IsInt()
  @Min(0)
  age?: number;
}
```

Ein DTO ist eine einfache Klasse, die die erwarteten Daten beschreibt, mit **Validierungsdekoratoren** (aus `class-validator`), die die Regeln angeben, die jedes Feld erfüllen muss.

## Einen DTO in einem Controller verwenden

```ts
@Post()
create(@Body() dto: CreateUserDto) {     // the body is typed AND validated as CreateUserDto
  // dto is guaranteed to be valid here (with the validation pipe enabled)
  return this.usersService.create(dto);
}
```

Das `@Body() dto: CreateUserDto` typisiert den Request-Body und — mit aktiviertem Validation Pipe — validiert ihn automatisch, bevor Ihr Handler ausgeführt wird.

## Automatische Validierung aktivieren

```ts
// main.ts — turn on the global validation pipe
app.useGlobalPipes(new ValidationPipe({
  whitelist: true,              // strip properties NOT in the DTO (security)
  forbidNonWhitelisted: true,   // reject requests with extra unknown properties
  transform: true,              // auto-transform payloads to DTO instances + convert types
}));
```

Mit dem `ValidationPipe` validiert NestJS eingehende Bodies automatisch gegen die Dekoratoren des DTO — es gibt einen 400-Fehler mit Details zurück, wenn die Validierung fehlschlägt, bevor Ihr Code ausgeführt wird.

## DTOs vs Entities

```text
DTO    → the shape of data crossing the API boundary (request/response contract)
Entity → the database model (e.g. a TypeORM entity / Prisma model)
→ Keep them SEPARATE: the API contract shouldn't be coupled to the DB schema.
  (A CreateUserDto has password+email; the User entity has id, timestamps, etc.)
```

DTOs unterscheiden sich absichtlich von Datenbankentitäten — sie repräsentieren, was die API akzeptiert/zurückgibt, entkoppelt vom internen Speicher.

## Variationen und Wiederverwendung

```ts
import { PartialType } from "@nestjs/mapped-types";
// derive an UpdateUserDto where all fields are optional — no duplication
export class UpdateUserDto extends PartialType(CreateUserDto) {}
```

## Warum es wichtig ist

DTOs sind ein wichtiges NestJS-Muster, das Typsicherheit, klare API-Verträge und automatische Validierung in Ihre Endpoints bringt.

Sie definieren genau, welche Daten ein Endpoint akzeptiert (die Request-Form), geben Ihnen Typisierung zur Compile-Zeit und dienen als selbstdokumentierende Verträge.

Entscheidend ist: In Kombination mit `class-validator`-Dekoratoren und dem `ValidationPipe` ermöglichen sie **automatische Eingabevalidierung** — schlecht formatierte oder böswillige Anfragen werden mit klaren Fehlern abgelehnt, *bevor* sie Ihre Business-Logik erreichen. Dies ist essentiell für Sicherheit und Robustheit (die `whitelist`-Option entfernt auch unerwartete Eigenschaften).

Das Verständnis von DTOs, wie man Validierungsregeln hinzufügt, wie man den Validation Pipe aktiviert, und das wichtige Prinzip, **DTOs getrennt von Datenbankentitäten zu halten** (Entkopplung des API-Vertrags vom internen Speicher), ist grundlegend für den Aufbau sicherer, gut strukturierter, wartbarer NestJS-APIs.

DTOs erscheinen in praktisch jedem Endpoint, der Input akzeptiert, und sind daher alltägliches, essentielles Wissen.