NestJs技术问询：为何不用DTO替代所有接口？能否以DTO为校验可信源？

Great questions—these are super common points of confusion when working with NestJS, since DTOs and interfaces both touch on type safety but serve very distinct roles. Let’s unpack each one clearly:

Why can’t we replace all interfaces with DTOs? #

The key divide comes down to runtime vs. compile-time behavior:

• DTOs are classes that exist at runtime. They carry not just type information, but also validation logic (via class-validator decorators) and can be instantiated as concrete objects.
• Interfaces are pure TypeScript constructs that only exist during development. They get erased from the final JavaScript bundle, acting solely as a way to enforce type safety before your code runs.

Replacing all interfaces with DTOs would introduce unnecessary bloat and overhead. For example:

• If you need to define a type for internal service logic (like describing the shape of a database query result), an interface is lighter and more appropriate—you don’t need validation or instantiation here.
• Interfaces shine at describing complex type relationships (union types, cross types, generic structures) that don’t require a runtime representation. A DTO can’t easily replicate something like type UserRole = 'admin' | 'user' | 'moderator' without adding pointless class boilerplate.

Can we use DTOs as a trusted validation source in both controllers and services? #

Absolutely! DTOs are meant to be your single source of truth for input validation, and reusing them across controllers and services keeps your validation rules consistent.

In controllers, you’re already using ValidationPipe to auto-validate incoming requests against your DTOs. For services, if you want to enforce the same rules for internal data (e.g., processing data before saving to the database), you can manually call the class-validator library’s validation functions:

import { validate } from 'class-validator';
import { CreateUserDto } from './dto/create-user.dto';
import { BadRequestException } from '@nestjs/common';

async processUser(userData: CreateUserDto) {
  const validationErrors = await validate(userData);
  if (validationErrors.length > 0) {
    throw new BadRequestException('Invalid user data provided');
  }
  // Proceed with your business logic
}

Just note: services sometimes handle data that doesn’t need strict external validation (like data pulled directly from the database). In those cases, an interface might be a better fit to describe the data shape without extra validation overhead.

Why do we still need interfaces if we have DTOs? #

Interfaces fill critical gaps that DTOs can’t cover, even with robust DTOs in place:

• Compile-time safety without runtime cost: Interfaces catch type errors during development without adding extra code to your production bundle. This is ideal for internal type checks (e.g., ensuring a service method returns the correct data shape).
• Flexible type definitions: Interfaces support generics, union types, and optional property combinations far more naturally than classes. For example, a PaginatedResult<T> interface can describe paginated data for any resource—something that’s clunky to replicate with a generic DTO class.
• Decoupling concerns: Interfaces let you separate data structure definitions from validation logic. For instance, you might have an IUser interface describing the core user shape, and a CreateUserDto that adds validation rules for external inputs. If you ever need to tweak validation rules, you don’t have to modify the interface used by your services.
• Readability and clarity: Interfaces signal that you’re defining a pure data structure, while DTOs signal validation and input handling. This makes your code more readable—other developers instantly grasp the purpose of each type.

内容的提问来源于stack exchange，提问作者Heather Lau