NestJS中DTO使用规范与职责划分指南

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《NestJS中DTO方法使用的最佳实践与职责划分 》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

数据传输对象（DTO）在NestJS中主要用于封装和验证请求或响应数据，其核心职责是保持简洁和无业务逻辑。本文探讨了在DTO中添加公共方法的边界，指出虽然特定于DTO内部数据的简单操作可能被接受，但通用的数据转换（如大小写转换）和所有业务逻辑都应通过NestJS的转换管道、装饰器或服务层来处理，以维护清晰的职责分离和代码可维护性。

理解数据传输对象（DTO）的核心职责

在NestJS等现代后端框架中，数据传输对象（DTO）是定义数据结构、实现数据验证和确保类型安全的关键组件。它们作为应用程序不同层之间数据交换的载体，例如从客户端接收请求体、或向客户端发送响应数据。DTO的核心职责应保持简单和纯粹：

• 数据封装： 定义预期的数据字段及其类型。
• 数据验证： 利用class-validator等库的装饰器，对传入数据进行格式、非空等基础检查。
• 类型安全： 为数据提供明确的TypeScript类型定义，增强代码的可读性和可维护性。

重要的是，DTO通常被视为“哑”对象，即它们主要承载数据，而不包含改变系统状态、执行复杂计算或与外部服务交互的业务逻辑。

在DTO中添加公共方法的考量

关于在DTO中添加公共方法，业界存在不同的观点。普遍的共识是，DTO应尽量保持无行为（behavior-less）。然而，在某些特定场景下，如果方法严格限定于DTO内部数据的操作，并且不涉及业务逻辑，则可能被接受。

何时可以考虑在DTO中添加方法？

如果方法满足以下严格条件，可以谨慎考虑：

• 仅限于DTO内部数据的特定操作： 方法的功能必须是针对DTO自身所包含的数据进行非常具体的、原子性的操作，且该操作的结果仍然是DTO数据的一种表现或转换。例如，将DTO中多个字段组合成一个DTO特有的、格式化的字符串表示，且此操作不依赖于外部状态或业务规则。
• 序列化/反序列化机制： 虽然在NestJS中通常由框架或库（如class-transformer）处理，但在某些特殊场景下，DTO可能需要自定义的序列化或反序列化逻辑。

关键原则： 任何添加到DTO中的方法，都应是其数据表示层的一部分，而不是业务逻辑层的一部分。

何时不应在DTO中添加方法？

以下情况绝不应在DTO中添加方法：

• 业务逻辑： 任何涉及数据库操作、第三方服务调用、复杂的业务规则判断、权限检查等都属于业务逻辑，应在服务（Service）层处理。DTO是数据载体，不是业务处理器。
• 通用数据转换或格式化： 例如将字符串转换为小写、修剪空格、日期格式化等。这些是通用的数据处理任务，不应与特定DTO绑定。它们应该通过更通用的机制来实现，如NestJS的转换管道、自定义@Transform()装饰器或独立的工具函数（helper）。
• 复杂验证逻辑： 虽然DTO支持使用class-validator进行基础验证，但涉及跨字段依赖、数据库查询或外部服务调用的复杂验证逻辑，更适合在服务层或自定义验证管道中实现。

替代方案与最佳实践

为了维护DTO的简洁性并实现职责分离，NestJS提供了强大的工具和模式来处理数据转换和验证，同时将业务逻辑隔离到服务层。

1. 利用NestJS的转换管道与class-transformer

对于通用的数据转换，class-transformer库（NestJS内置支持）提供了强大的@Transform()装饰器。这比在DTO中编写方法更为优雅和可复用。

不推荐的DTO方法示例：

export class CreateCustomerDto {
  name: string;
  // ... 其他字段

  public setLowercaseName() { // 不推荐：通用数据转换不应在DTO方法中
    return this.name.toLowerCase();
  }
}

推荐使用@Transform()的DTO示例：

import { IsString, IsNotEmpty } from 'class-validator';
import { Transform } from 'class-transformer';

export class CreateCustomerDto {
  @IsString()
  @IsNotEmpty()
  @Transform(({ value }) => value.toLowerCase()) // 使用 @Transform 进行转换
  name: string;

  @IsString()
  @IsNotEmpty()
  @Transform(({ value }) => value.trim()) // 另一个示例：修剪空格
  address: string;

  // ... 其他字段，不再包含方法
}

通过这种方式，数据在进入控制器或服务之前，就会被管道自动转换。这使得DTO保持了其数据结构的纯粹性，同时将转换逻辑声明性地附加到字段上。

2. 服务层处理业务逻辑

任何涉及业务规则、数据持久化或与其他模块交互的逻辑，都应在服务层（Service）中实现。服务是应用程序的核心，负责协调数据流和执行业务操作。

import { Injectable } from '@nestjs/common';
import { CreateCustomerDto } from './dto/create-customer.dto';
import { Customer } from './entities/customer.entity'; // 假设有 Customer 实体

@Injectable()
export class CustomersService {
  constructor(
    // 注入数据库仓库或其他依赖
  ) {}

  async create(createCustomerDto: CreateCustomerDto): Promise<customer> {
    // 此时 createCustomerDto.name 已经被 @Transform 转换为小写
    // 可以在这里执行更复杂的业务逻辑，例如：
    // 1. 检查客户名是否已存在
    // 2. 根据业务规则生成客户编号
    // 3. 将 DTO 数据映射到实体并保存到数据库
    const newCustomer = new Customer();
    newCustomer.name = createCustomerDto.name;
    newCustomer.address = createCustomerDto.address;
    // ... 其他属性

    // return this.customerRepository.save(newCustomer);
    return newCustomer; // 示例
  }
}
</customer>

3. 工具函数（Helper Functions）

对于不属于特定DTO或服务，但又经常需要使用的通用数据处理逻辑，可以创建独立的工具函数或Helper模块。这样可以提高代码的复用性和可测试性。

总结

在NestJS中，DTO的核心价值在于其作为数据传输和验证的简洁载体。虽然在极端有限的场景下，DTO可以包含一些严格限于其内部数据操作的公共方法，但最佳实践是避免在DTO中引入任何形式的业务逻辑或通用数据转换。相反，应充分利用NestJS提供的class-validator和class-transformer进行声明式的数据验证和转换，并将所有业务逻辑严格封装在服务层。这种职责分离不仅能使DTO保持轻量和纯粹，还能显著提升代码的可读性、可维护性和可测试性。

本篇关于《NestJS中DTO使用规范与职责划分指南》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！