Hvad er DTOs i NestJS?

Question

Accepted Answer

En **DTO (Data Transfer Object)** er en klasse, der definerer **formen på data**, der sendes til eller fra dit API — typisk strukturen på en request body. DTOs giver type-sikkerhed, tjener som en klar kontrakt for endpoints, og (med validerings-decoratorer) aktiverer automatisk input-validering.

## Definering af en DTO

```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;
}
```

En DTO er en simpel klasse, der beskriver de forventede data, med **validerings-decoratorer** (fra `class-validator`), der specificerer de regler, hvert felt skal overholde.

## Brug af en DTO i en controller

```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);
}
```

`@Body() dto: CreateUserDto` typificerer request body'en og — med validerings-pipen aktiveret — validerer den automatisk før din handler køres.

## Aktivering af automatisk validering

```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
}));
```

Med `ValidationPipe` validerer NestJS indgående bodies mod DTO'ens decoratorer automatisk — og returnerer en 400-fejl med detaljer, hvis validering mislykkes, før din kode køres.

## 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 adskiller sig bevidst fra database-entities — de repræsenterer, hvad API'et accepterer/returnerer, adskilt fra intern lagring.

## Variationer og genbrug

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

## Hvorfor det betyder noget

DTOs er et vigtigt NestJS-mønster, der bringer type-sikkerhed, klare API-kontrakter og automatisk validering til dine endpoints.

De definerer præcis, hvilke data et endpoint accepterer (request-formen), hvilket giver dig compile-time typing og tjener som selvdokumenterende kontrakter.

Kritisk set, kombineret med `class-validator`-decoratorer og `ValidationPipe`, aktiverer de **automatisk input-validering** — malformede eller ondsindet requests afvises med klare fejl *før* de når til din business logic, hvilket er afgørende for sikkerhed og robusthed (`whitelist`-optionen fjerner også uventede egenskaber).

At forstå DTOs, hvordan man tilføjer validerings-regler, hvordan man aktiverer validerings-pipen, og det vigtige princip om at **holde DTOs separate fra database-entities** (adskille API-kontrakten fra intern lagring) er fundamentalt for at bygge sikre, velstrukturerede, vedligeholdelige NestJS-API'er.

DTOs optræder i stort set alle endpoints, der accepterer input, hvilket gør dem til hverdags- og væsentlig viden.