Spring Validation 의 @field:NotBlank 등으로 Request DTO 필드 검증 시, 필드타입 선언방식( non-null or nullable )

안녕하세요! Truestar님!! 정말 좋은 질문 감사드립니다! 😊

결론부터 말씀드려보면 저는 DTO validation 과정에서 spring-validator를 사용하지 않는 편입니다!!!

저는 spring-validator를 사용하기 보다는 직접 validation 해주는 것을 선호해요! 😊 (매우 개인적인 의견입니다!)

예를 들어, 말씀해주신 것과 같이 특정 필드가 email이어야 한다면, 아래와 같이 코드를 작성할 것 같습니다!

data class UserCreateRequest(
    val email: String, // (1)
) {

    fun toCommand(): UserCreate {
      require(email.isEmail()) // (2)
      return UserCreate(email = email)
    }
}

하나씩 설명드려볼게요!

[1. val email: String]

우선 email을 받을 때 굳이 Blank인지 확인하지 않습니다! 또한, null이 들어오는 경우는 DTO 변환 과정에서 실패해도 괜찮다고 생각해서 처음부터 String 으로 받습니다.

[2. require() + isEmail]

다음으로는 코틀린에서 제공해주는 함수인 require를 사용해 주어진 email 필드가 이메일 포맷인지 확인할 것 같아요! 이때 isEmail() 은 미리 만들어둔 확장 함수로 생각할 수 있습니다! 😊

이런 방법을 사용하면, 고민하시던 String? -> String 을 굳이 사용하지 않아도 괜찮습니다.

또한, 개인적으로 이 방법을 선호하는 이유는, 예외 처리를 조금 더 custom 하게 할 수 있기 때문입니다.

예를 들어 원래는 email 포맷이 아니었던 경우 아무 에러나 던져줘도 괜찮았는데, 이제부터 이메일 포맷이 잘못되었음을 사용자에게 알려주어야 한다면?! 혹은 email 검증 과정에서 조금 특별한 규칙이 추가되어야 한다면?! (정해진 도메인의 이메일만 허용한다거나...)

이렇게 요구사항이 바뀌는 경우 spring-validator를 사용하는 것보다 조금 더 유연하게 대처할 수 있다 보니 개인적으로는 이런 검증 방식을 쓰고 있는 것 같습니다.

다만, "우아하지 못한 단언 !!" 이라 표현해주신 것처럼 외부와의 경계점에서는 불가피하게 !! 를 사용해야 하는경우가 꽤 있었습니다. API 쪽일 수도 있고, DB 쪽일 수도 있는데요! 이런 경우 정말 어쩔 수 없이 !! 를 사용해야 한다면 말씀해주신 backing property로 nullable type -> non-nullable type 변환 작업을 한 번쯤 해주는 편입니다 ㅎㅎㅎㅎ..

답변이 도움이 되었다면 좋겠습니다. 감사합니다!! 🙇🙇