Spring Boot用户CRUD接口模型设计困惑：多请求类重复问题求解

我太懂这种纠结了——用同一个User实体类搞定所有CRUD的输入输出，要么会暴露不必要的属性（比如创建用户时传id），要么得写一堆注释；拆分多个DTO吧，又要重复写校验规则，代码看着特别冗余。结合Spring生态，有几个实用的方案可以解决这个问题：

方案1：Jackson JsonView + Bean Validation分组校验 #

这个方案的核心是复用同一个User实体类，通过视图控制哪些属性序列化/反序列化，再用校验分组区分不同场景的校验规则。

步骤： #

1. 定义不同场景的视图接口：

public interface UserViews {
    // 创建用户时的视图（输入/输出）
    interface Create {}
    // 获取用户详情的视图（输出）
    interface Get {}
    // 更新个人信息的视图（输入/输出）
    interface UpdatePersonal {}
    // 更新密码的视图（输入）
    interface UpdatePassword {}
    // 解锁用户的视图（输入）
    interface Unlock {}
}

2. 在User类的属性上标注@JsonView和分组校验注解：

class User {
    // 仅在获取、更新类接口中展示/接收
    @JsonView({UserViews.Get.class, UserViews.UpdatePersonal.class, UserViews.UpdatePassword.class, UserViews.Unlock.class})
    long id;

    // 创建时必填，更新时可选，获取时展示
    @JsonView({UserViews.Create.class, UserViews.Get.class, UserViews.UpdatePersonal.class})
    @NotBlank(groups = UserValidationGroups.Create.class)
    @Nullable(groups = UserValidationGroups.UpdatePersonal.class)
    String displayName;

    // 创建和更新时都要符合邮箱格式，创建时必填
    @JsonView({UserViews.Create.class, UserViews.Get.class, UserViews.UpdatePersonal.class})
    @Email(groups = {UserValidationGroups.Create.class, UserValidationGroups.UpdatePersonal.class})
    @NotBlank(groups = UserValidationGroups.Create.class)
    String email;

    // 永远不参与序列化/反序列化（内部存储用）
    @JsonView({})
    String passwordHash;

    @JsonView({})
    String passwordSalt;

    // 创建时自动生成，无需前端传入，也不返回给前端
    @JsonView({UserViews.Create.class})
    Instant passwordExpiryDate;

    // 获取和解锁时展示/操作
    @JsonView({UserViews.Get.class, UserViews.Unlock.class})
    boolean locked;

    // 所有更新类接口都需要传入version做乐观锁
    @JsonView({UserViews.UpdatePersonal.class, UserViews.UpdatePassword.class, UserViews.Unlock.class})
    @NotNull(groups = {UserValidationGroups.UpdatePersonal.class, UserValidationGroups.UpdatePassword.class, UserValidationGroups.Unlock.class})
    Instant version;
}

// 对应的校验分组
public interface UserValidationGroups {
    interface Create {}
    interface UpdatePersonal {}
    interface UpdatePassword {}
    interface Unlock {}
}

3. 在Controller接口上指定视图和校验分组：

@PostMapping("/users")
@JsonView(UserViews.Create.class)
public ResponseEntity<User> createUser(
        @RequestBody @Validated(UserValidationGroups.Create.class) @JsonView(UserViews.Create.class) User user
) {
    // 处理创建逻辑，自动生成id、passwordHash等属性
    return ResponseEntity.ok(savedUser);
}

@PutMapping("/users/{id}")
public ResponseEntity<User> updatePersonalInfo(
        @PathVariable long id,
        @RequestBody @Validated(UserValidationGroups.UpdatePersonal.class) @JsonView(UserViews.UpdatePersonal.class) User user
) {
    // 处理更新逻辑
    return ResponseEntity.ok(updatedUser);
}

优点： #

• 不用创建大量DTO类，代码结构更简洁
• 校验规则集中在User类，避免重复定义
• 前端能清晰看到每个接口需要传/接收哪些属性

缺点： #

• 视图和分组多了之后，User类上的注解会变复杂，可读性略有下降
• 无法处理和实体类结构完全不同的请求（比如更新密码需要明文密码，而实体类只有hash）

方案2：少量专用DTO + MapStruct自动映射 #

如果有些场景的请求结构和实体类差异很大（比如更新密码需要传入明文密码），可以保留少量专用DTO，用MapStruct自动处理DTO和实体类的映射，减少手动写get/set的冗余。

步骤： #

1. 定义专用DTO，复用公共校验规则：

// 所有更新类请求的基类，包含version的校验
abstract class BaseUpdateRequest {
    @NotNull
    Instant version;
}

// 更新个人信息的DTO
class UpdatePersonalRequest extends BaseUpdateRequest {
    @Nullable
    @Email
    String email;

    @Nullable
    String displayName;
}

// 更新密码的DTO（需要明文密码，实体类没有这个属性）
class UpdatePasswordRequest extends BaseUpdateRequest {
    @NotBlank
    String newPassword;
}

2. 配置MapStruct映射器：

@Mapper(componentModel = "spring")
public interface UserMapper {
    // 把UpdatePersonalRequest的属性映射到已有的User实体
    void updatePersonalFromRequest(UpdatePersonalRequest request, @MappingTarget User user);
}

3. 在Controller中使用DTO：

@PutMapping("/users/{id}/password")
public ResponseEntity<Void> updatePassword(
        @PathVariable long id,
        @RequestBody @Valid UpdatePasswordRequest request
) {
    User user = userRepository.findById(id).orElseThrow();
    // 校验version乐观锁
    if (!user.getVersion().equals(request.getVersion())) {
        throw new OptimisticLockingFailureException("User has been updated by another process");
    }
    // 生成passwordHash和salt
    String salt = generateSalt();
    String hash = hashPassword(request.getNewPassword(), salt);
    user.setPasswordHash(hash);
    user.setPasswordSalt(salt);
    user.setPasswordExpiryDate(Instant.now().plus(30, ChronoUnit.DAYS));
    userRepository.save(user);
    return ResponseEntity.noContent().build();
}

优点： #

• API契约非常清晰，前端一看就知道每个接口需要传什么
• MapStruct自动处理映射，减少重复代码
• 专用DTO可以灵活定义和实体类不同的结构

缺点： #

• 还是需要维护少量DTO类，但数量比全量拆分少很多

方案3：使用Spring Data Projections（仅适用于响应输出） #

如果只是输出时需要隐藏部分属性，可以用Spring Data的Projection功能，不用修改实体类，也不用创建DTO。

步骤： #

1. 定义Projection接口：

// 获取用户详情时的投影，隐藏id、passwordHash等属性
public interface UserWithoutIdProjection {
    String getDisplayName();
    String getEmail();
    boolean isLocked();
}

2. 在Repository中使用Projection：

public interface UserRepository extends JpaRepository<User, Long> {
    UserWithoutIdProjection findById(long id);
}

3. 在Controller中返回Projection：

@GetMapping("/users/{id}")
public ResponseEntity<UserWithoutIdProjection> getUser(@PathVariable long id) {
    UserWithoutIdProjection user = userRepository.findById(id);
    return ResponseEntity.ok(user);
}

优点： #

• 无需修改实体类，快速定义输出结构
• 适合只需要调整输出的场景

缺点： #

• 只能用于响应输出，无法处理请求输入的校验和属性过滤

总结建议 #

• 如果你的API请求/响应和实体类结构差异不大，优先选方案1（JsonView+分组校验），代码最简洁，复用性最高；
• 如果有部分请求需要和实体类完全不同的结构（比如更新密码），结合方案1+方案2，用JsonView处理大部分场景，少量特殊场景用专用DTO；
• 如果只是需要调整输出结构，用**方案3（Spring Data Projections）**快速解决。

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