NestJS में DTOs क्या होते हैं?

Question

Accepted Answer

एक **DTO (Data Transfer Object)** एक class है जो आपके API को भेजे जाने वाले या उससे लौटाए जाने वाले **data की संरचना** परिभाषित करती है — आमतौर पर किसी request body की संरचना। DTOs type safety प्रदान करते हैं, endpoints के लिए एक स्पष्ट contract के रूप में काम करते हैं, और (validation decorators के साथ) स्वचालित input validation को सक्षम करते हैं।

## एक 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;
}
```

एक DTO एक सरल class है जो अपेक्षित data का वर्णन करती है, जिसमें **validation decorators** (`class-validator` से) प्रत्येक field के लिए नियम निर्दिष्ट करते हैं।

## controller में एक DTO का उपयोग

```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` request body को type करता है और — validation pipe सक्षम होने पर — आपके handler के चलने से पहले उसे स्वचालित रूप से validate करता है।

## स्वचालित validation सक्षम करना

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

`ValidationPipe` के साथ, NestJS आने वाली bodies को DTO के decorators के विरुद्ध स्वचालित रूप से validate करता है — और validation विफल होने पर, आपके code के चलने से पहले विवरण के साथ एक 400 error लौटाता है।

## DTOs बनाम 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 जानबूझकर database entities से भिन्न होते हैं — वे यह दर्शाते हैं कि API क्या स्वीकार/लौटाता है, जो आंतरिक storage से अलग रहता है।

## विविधताएँ और पुनः उपयोग

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

## यह क्यों महत्वपूर्ण है

DTOs एक महत्वपूर्ण NestJS pattern हैं जो आपके endpoints में type safety, स्पष्ट API contracts और स्वचालित validation लाते हैं।

वे ठीक-ठीक परिभाषित करते हैं कि कोई endpoint क्या data स्वीकार करता है (request की संरचना), जिससे आपको compile-time typing मिलती है और जो स्व-दस्तावेज़ीकृत contracts के रूप में काम करते हैं।

महत्वपूर्ण रूप से, `class-validator` decorators और `ValidationPipe` के साथ मिलकर, वे **स्वचालित input validation** सक्षम करते हैं — विकृत या दुर्भावनापूर्ण requests को आपके business logic तक पहुँचने से *पहले* स्पष्ट errors के साथ अस्वीकार कर दिया जाता है, जो security और मज़बूती के लिए आवश्यक है (`whitelist` विकल्प अप्रत्याशित properties को भी हटा देता है)।

DTOs को समझना, validation नियम कैसे जोड़ें, validation pipe कैसे सक्षम करें, और **DTOs को database entities से अलग रखने** के महत्वपूर्ण सिद्धांत (API contract को आंतरिक storage से अलग करना) को समझना सुरक्षित, सुव्यवस्थित, अनुरक्षणीय NestJS APIs बनाने के लिए मौलिक है।

DTOs वस्तुतः हर उस endpoint में दिखाई देते हैं जो input स्वीकार करता है, जिससे वे रोज़मर्रा का, आवश्यक ज्ञान बन जाते हैं।