API数据传输对象（DTO）在创建与更新场景下的验证实践

admin 百科 2025-12-12 20

在api设计中，当同一个数据传输对象（dto）需要支持创建和更新操作时，常常会遇到字段验证规则不一致的问题，例如某些字段在创建时强制要求，而在更新时可选。本文将探讨如何优雅地处理这种场景，通过在后端业务逻辑层进行条件验证，而非过度依赖dto层面的注解，从而实现灵活且可维护的验证策略。

API数据传输对象（DTO）在创建与更新场景下的验证实践-第2张图片-佛山资讯网

DTO在创建与更新操作中的验证挑战

在开发RESTful API时，我们经常使用数据传输对象（DTO）来封装客户端发送的数据。一个常见的场景是，一个UserDto可能被用于创建新用户和更新现有用户信息。

考虑以下UserDto定义：

public class UserDto {
  @NotBlank(message = "用户名不能为空")
  private String username;

  @NotBlank(message = "密码不能为空")
  private String password;

  @NotBlank(message = "手机号不能为空")
  private String mobileNo;

  // ... 其他字段及Getter/Setter方法
}

登录后复制

对于创建用户操作，username、password和mobileNo都是必填项，因此@NotBlank注解是合适的。然而，当进行更新操作时，我们可能不希望更新用户的密码，或者只允许更新部分字段（例如mobileNo）。在这种情况下，如果客户端在更新请求中不提供password字段（或提供null），@NotBlank验证就会失败，即使业务逻辑允许密码不更新。

这种矛盾导致了两种常见的解决方案：

为每个操作创建独立的DTO： 例如，UserCreateDto和UserUpdateDto。
使用单个DTO，但在后端进行条件验证。

本文将重点探讨第二种方案，因为它能有效减少DTO类的数量，并提供更灵活的验证控制。

方案一：为不同操作创建独立DTO（简要讨论）

为创建和更新操作分别创建UserCreateDto和UserUpdateDto是一种直观的解决方案。

UserCreateDto:

public class UserCreateDto {
  @NotBlank(message = "用户名不能为空")
  private String username;
  @NotBlank(message = "密码不能为空")
  private String password;
  @NotBlank(message = "手机号不能为空")
  private String mobileNo;
  // ...
}

登录后复制

UserUpdateDto:

public class UserUpdateDto {
  // 更新时可能不需要用户名，或者有不同的验证规则
  private String username;
  // 更新时密码可选，因此不加@NotBlank
  private String password;
  @NotBlank(message = "手机号不能为空") // 手机号在更新时可能仍是必填
  private String mobileNo;
  // ...
}

登录后复制

优点：