DTO 엔티티 validation과 List<DTO>

🤔
DTO와 엔티티 중 validation을 어디에 걸어야 할까?

 

DDD를 도입하는 초기 단계여서 그런지 위같은 질문이 계속해서 들었다.

책에서 배운 걸 떠올렸을 때에는 다음과 같다.

• 타입에 대한 검증은 컨트롤러 이전인 DTO에서 처리되어야 한다.
• 비즈니스적인 유효성 검증은 domain 엔티티에서 처리되어야 한다.

하지만 아래 나와있다시피 비즈니스 규칙을 검증하기가 여의치 않다면 도메인 엔티티 사용전에 사용해도 된다.

그래서 결론을 내린 게 입력명 길이나 필수값을 DTO에서 처리하기로 했다.

다음은 상점을 만드는 DTO 예시 코드와 같다.

import lombok.Builder;
import lombok.Getter;
import net.logstash.logback.util.StringUtils;

import javax.validation.constraints.*;

@Getter
public class StoreCreateDto {
    @NotBlank(message = "[상점명]은 필수값입니다.")
    @Size(max = STORE_NAME_MAX_LENGTH, message = "[상점명]은 50자를 초과할 수 없습니다.")
    private final String name;
    @Pattern(regexp = PHONE_NUMBER_PATTERN, message = "올바른 전화번호 형식이 아닙니다. 02-1234-1234와 같은 형식으로 입력해 주세요.")
    private final String contact;
    @NotNull(message = "[상점유형]은 필수값입니다.")
    private final StoreType type;
    private final StoreAddress address;

    @AssertFalse(message = "[우편번호]는 필수값입니다.")
    private boolean isNullZipcode() {
        return StringUtils.isBlank(address.getZipcode());
    }

    @AssertFalse(message = "[주소]는 필수값입니다.")
    private boolean isNullMainAddress() {
        return StringUtils.isBlank(address.getMainAddress());
    }

    @AssertFalse(message = "[주소]는 100자를 초과할 수 없습니다.")
    private boolean isValidMainAddress() {
        return address.getMainAddress().length() > MAIN_ADDRESS_MAX_LENGTH;
    }

    @AssertFalse(message = "[상세주소]는 60자를 초과할 수 없습니다.")
    private boolean isValidSubAddress() {
        return !StringUtils.isBlank(address.getSubAddress())
                && address.getSubAddress().length() > SUB_ADDRESS_MAX_LENGTH;
    }
}

🤔
DTO 타입의 List에 대한 validation은 어떻게 해야 할까?

 

두 번째 다뤄볼 내용은 DTO 타입의 List에 대한 validation은 어떻게 할까이다.

validation하는 세 가지 방법을 소개하려고 한다.

[1]. inner static class로 이용

내부 클래스 DTO를 감싸는 List<DTO>를 만드는 방법이다.

@Getter
@NoArgsConstructor
public class StoreUpdateListDto {
    List<@Valid StoreUpdateDto1> listDto;
    
    public static class StoreUpdateDto1 {
        // ...
    }
}

장점

• DTO 개수를 줄일 수 있다.

단점

• 이펙티브 자바에서는 내부 클래스는 되도록 static으로 만들라고 나와있긴 한데, 중첩 클래스는 자신을 감싼 바깥 클래스에만 쓰여야 하며, 그 외의 쓰임새가 있다면 톱레벨 클래스로 만들어야 한다고는 나와있다.
  • 즉, 나중에 유지보수가 힘들어진다.

[2]. DTO 2개 생성

DTO 한개, 그 DTO를 감싸는 List<DTO> 총 두 개를 만드는 방법이다.

@Getter
@NoArgsConstructor
public class StoreUpdateListDto {
    List<@Valid StoreUpdateDto> listDto;
}

@Getter
public class StoreUpdateDto {
    // ...
}

장점

• DTO의 사용 목적을 분리할 수 있다.
  • 요청으로 받은 StoreUpdateListDto는 요청 스펙으로서의 역할
  • StoreUpdateDto는 위에서 검증된 걸 사용하는 DTO로서의 역할

단점

• DTO 개수가 많아질 수 있다.

[3]. List를 구현하는 ValidList 생성

validation이 필요한 List에는 List가 아닌 ValidList를 사용하는 방법이다.

List에 Valid 어노테이션과 Delegate 어노테이션을 붙인 ValidList를 만든다.

@Getter
public class ValidList<E> implements List<E> {
    @Valid
    @Delegate
    private List<E> list;

    public ValidList() {
        this.list = new ArrayList<>();
    }

    public ValidList(List<E> list) {
        this.list = list;
    }
}

@PutMapping("")
public ResponseEntity<?> updateStore(@Valid @RequestBody ValidList<StoreUpdateDto> storeDtos) {
    List<String> ids = storeService.updateStores(storeDtos);
    return ResponseEntity.ok().body(new CommonResponse(new DataResponse<>(ids)));
}

장점

• DTO 개수를 줄일 수 있다.

단점

• list가 아니라 map이나 set으로 받게 되면 그것도 Valid-를 다 만들어야 함.