DTO et validation automatique

Objectifs

À la fin de cette leçon, vous saurez :

• déclarer un DTO avec class-validator ;
• activer la ValidationPipe globale ;
• comprendre pourquoi le type TS ne suffit pas.

🔗 Pour vous rafraîchir la mémoire : les bases TypeScript

Le DTO : contrat d'entrée explicite

// dto/create-task.dto.ts
export class CreateTaskDto {
  @IsString()
  @IsNotEmpty()
  @MaxLength(200)
  titre!: string;

  @IsOptional()
  @IsBoolean()
  fait?: boolean;
}

Chaque décorateur = une règle de validation exécutable. Comparez avec votre vanilla : c'est votre bloc if (typeof titre !== "string" || ...), déclaré déclarativement.

Le pipe global qui fait respecter

// main.ts
app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));

Désormais toute requête invalide reçoit automatiquement :

{ "statusCode": 400, "message": ["titre must be a string"] }

sans une ligne dans vos contrôleurs — et le service ne reçoit JAMAIS de donnée non validée.

Pourquoi les types TS ne suffisent pas

Rappel du chapitre TypeScript : un type n'existe qu'à la compilation. Un JSON entrant est inconnu au runtime :

creer(dto: CreateTaskDto)   // TS fait confiance... à tort si le client ment

Le DTO validé par le pipe ajoute ce que les types ne peuvent pas faire : l'inspection RÉELLE des données à leur arrivée. Type = confort de développement ; ValidationPipe = sécurité à l'exécution. Les deux sont indispensables — c'est exactement l'architecture de Devmind (ValidationPipe global + class-validator partout).

Exercice

1. Ajoutez @MaxLength(200) puis testez avec 201 caractères : lisez le message.
2. Envoyez {"titre":"ok","pirate":true} avec whitelist : vérifiez que pirate disparaît.
3. Créez UpdateTaskDto avec PartialType(CreateTaskDto).
4. Pourquoi whitelist est-il une mesure de sécurité ?

Résumé

• DTO = règles déclarées ; ValidationPipe = exécution systématique.
• Erreurs 400 automatiques, service protégé en amont.
• Types ≠ validation runtime : le pipe complète TS.