Why DTO class creation in NestJS? - Purpose & Use Cases

The Big Idea

What if you could stop worrying about messy data and focus on building features instead?

The Scenario

Imagine building a web app where you manually check and copy every piece of user input before saving it to your database.

You write repetitive code to validate and transform data everywhere.

The Problem

Manually handling data transfer is slow and error-prone.

You might forget to validate some fields or accidentally allow wrong data formats.

This leads to bugs and security risks.

The Solution

DTO classes let you define clear data shapes and validation rules in one place.

They automatically check and transform incoming data before your app uses it.

Before vs After

✗ Before

const name = req.body.name;
if(typeof name !== 'string') throw new Error('Invalid name');

✓ After

import { IsString } from 'class-validator';

export class CreateUserDto {
  @IsString()
  name: string;
}

What It Enables

DTO classes make your code cleaner, safer, and easier to maintain by centralizing data validation and transformation.

Real Life Example

When a user signs up, a DTO class ensures their email and password meet rules before creating their account.

Key Takeaways

Manual data handling is repetitive and risky.

DTO classes define and validate data shapes clearly.

This leads to safer, cleaner, and more maintainable code.

Practice

1. What is the main purpose of a DTO class in a NestJS application?

easy

A. To handle database connections and queries

B. To create UI components for the frontend

C. To define the shape and validation rules of data transferred between layers

D. To manage application routing and middleware

Solution

1. Step 1: Understand the role of DTOs

   DTO stands for Data Transfer Object, used to define how data should look when sent or received.

2. Step 2: Identify what DTOs do in NestJS

   In NestJS, DTOs specify the structure and validation of data between client and server or between app layers.

3. Final Answer:

   To define the shape and validation rules of data transferred between layers -> Option C

4. Quick Check:

   DTO = Data shape and validation [OK]

Hint: DTOs organize and validate data structure in NestJS [OK]

Common Mistakes:

• Confusing DTOs with database models
• Thinking DTOs handle routing or UI
• Assuming DTOs manage middleware

2. Which of the following is the correct way to declare a required string property name in a NestJS DTO class using class-validator decorators?

easy

A. @IsString() name: string;

B. name: string;

C. @IsOptional() name: string;

D. @IsNumber() name: string;

Solution

1. Step 1: Identify the decorator for string validation

   The @IsString() decorator from class-validator ensures the property is a string and required by default.

2. Step 2: Check other options

   name: string; lacks validation, C marks it optional, and D wrongly uses number validation.

3. Final Answer:

   @IsString() name: string; -> Option A

4. Quick Check:

   Use @IsString() for required string fields [OK]

Hint: Use @IsString() to require string fields in DTOs [OK]

Common Mistakes:

• Omitting validation decorators
• Using @IsOptional() for required fields
• Applying wrong type decorators like @IsNumber()

3. Given this DTO class, what will be the result of validating an object { name: "Alice", age: 25 }?

import { IsString, IsInt, IsOptional } from 'class-validator';

export class UserDto {
  @IsString()
  name: string;

  @IsInt()
  @IsOptional()
  age?: number;
}

medium

A. Validation passes because name is string and age is optional integer

B. Validation fails because age is required but missing

C. Validation fails because name is not optional

D. Validation passes only if age is a string

Solution

1. Step 1: Analyze the DTO decorators

   Name is required string, age is optional integer due to @IsOptional() and @IsInt().

2. Step 2: Check the input object

   Input has name as string "Alice" and age as number 25, matching the DTO rules.

3. Final Answer:

   Validation passes because name is string and age is optional integer -> Option A

4. Quick Check:

   Required string + optional int with valid data = pass [OK]

Hint: Optional fields pass validation if present and valid [OK]

Common Mistakes:

• Assuming optional fields must be present
• Confusing @IsOptional() effect
• Thinking validation fails if optional field is present

4. Identify the error in this DTO class that causes validation to always fail for the email property:

import { IsEmail } from 'class-validator';

export class EmailDto {
  @IsEmail
  email: string;
}

medium

A. Should import IsString instead of IsEmail

B. email property should be optional

C. email property type should be number

D. Missing parentheses after @IsEmail decorator

Solution

1. Step 1: Check decorator usage

   @IsEmail is a function decorator and must be called with parentheses: @IsEmail()

2. Step 2: Understand effect of missing parentheses

   Without parentheses, the decorator is not applied properly, causing validation to fail.

3. Final Answer:

   Missing parentheses after @IsEmail decorator -> Option D

4. Quick Check:

   Decorators need () even if no args [OK]

Hint: Always add () after decorators like @IsEmail() [OK]

Common Mistakes:

• Forgetting parentheses on decorators
• Changing property type incorrectly
• Using wrong decorators for email

5. You want to create a DTO class CreateProductDto with these rules:
- title is a required string
- price is a required positive number
- description is an optional string
Which of the following DTO class definitions correctly implements these rules?

hard

A. import { IsString, IsNumber, IsPositive, IsOptional } from 'class-validator';

export class CreateProductDto {
@IsString()
title?: string;

@IsNumber()
@IsPositive()
price?: number;

@IsOptional()
@IsString()
description?: string;
}

B. import { IsString, IsNumber, IsPositive, IsOptional } from 'class-validator';

export class CreateProductDto {
@IsString()
title: string;

@IsNumber()
@IsPositive()
price: number;

@IsOptional()
@IsString()
description?: string;
}

C. import { IsString, IsNumber, IsPositive } from 'class-validator';

export class CreateProductDto {
@IsString()
title: string;

@IsNumber()
price: number;

@IsString()
description: string;
}

D. import { IsString, IsNumber, IsPositive, IsOptional } from 'class-validator';

export class CreateProductDto {
@IsString()
title: string;

@IsNumber()
price: number;

@IsOptional()
description?: string;
}

Solution

1. Step 1: Check required string property

   Title is required string, so @IsString() with no @IsOptional() is correct.

2. Step 2: Check required positive number property

   Price must be number and positive, so @IsNumber() and @IsPositive() are needed without @IsOptional().

3. Step 3: Check optional string property

   Description is optional string, so @IsOptional() and @IsString() with optional property syntax (?) is correct.

4. Final Answer:

   DTO with @IsString() title, @IsNumber() + @IsPositive() price, and optional @IsOptional() description -> Option B

5. Quick Check:

   Required fields no @IsOptional(), optional fields with @IsOptional() [OK]

Hint: Use @IsOptional() only on optional fields [OK]

Common Mistakes:

• Marking required fields as optional
• Missing @IsPositive() for positive number
• Omitting @IsOptional() on optional fields