Validator 클래스

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class LoginDto {

	@NotBlank
	private String email;

	@NotBlank
	private String password;
}
-------------------------------------
@Component
public class LoginValidator implements Validator {

    private final UserRepository userRepository;

    public LoginValidator(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public boolean supports(Class<?> clazz) {
        return LoginDto.class.isAssignableFrom(clazz);
    }

    @Override
    public void validate(Object target, Errors errors) {
        LoginDto loginDto = (LoginDto) target;
        User user = userRepository.findByEmail(loginDto.getEmail());

        if (user == null) {
            throw new LoginFailedException("User not found");
        }

        if (!user.getPassword().equals(loginDto.getPassword())) { 
            throw new LoginFailedException("Invalid password");
        }
    }
}

위 코드처럼 DTO 클래스에서 간단한 검증은 bean validation으로 시행하고, 복잡한 검증로직은 LoginValidator에서 관리 및 커스텀 예외를 리턴하는 방식은 안좋은 방식인가요?

제가 알기로는 errors는 bindingresult처럼 복잡한 검증이 아니라 단순한 검증결과를 담는 것으로 알고 있는데, validate를 override하여 복잡한 검증 실행 및 검증 결과를 LoginFailedException(커스텀 예외)으로 반환하려고 하니 Errors를 리턴해야 한다는 강제성 때문에 혼란이 생겼습니다.

따라서 제가 궁금한 점은, 간단한 검증작업(ex. 정규식) 과 복잡한 검증작업(ex.이메일,비밀번호가 DB에 있는지 검증)은 어떻게 처리하는게 이상적인가? 입니다. 저는 각각 Bean Validation, Validator(커스텀 예외 반환)로 해보려했는데 아닌 것 같아서 질문드립니다.

감사합니다.

안녕하세요, 인프런 AI 인턴입니다.

질문하신 내용은 스프링 백엔드 개발에서 매우 중요한 부분인 DTO 및 커스텀 Validator 사용에 대한 고민이군요. 질문 내용에 직접적으로 답변하지 못하더라도, 유사한 주제에 대해 다뤄진 과거의 질문을 찾아 드릴 수 있습니다.

비슷한 맥락에서, Validator 사용 범위 질문드립니다.이라는 게시글을 찾았습니다. 이 글에서는 Spring Validator의 사용에 대해 비슷한 고민을 한 다른 학습자의 질문과 강사님의 답변을 확인할 수 있습니다. Validator에서 데이터베이스와 연계된 검증을 포함하여 검증 로직을 어디까지 포함할 것인지에 대한 내용이 담겨 있습니다.

질문하신 내용과 구체적으로 일치하는 지침을 찾기 어려운 점 양해 부탁드립니다. 그러나, 일반적으로 Bean Validation과 Validator를 조합해 사용하는 방법은 자주 보이는 패턴 중 하나입니다. Bean Validation을 통해 기본적인 제약 조건을 검증하고, 여기서 간과하기 쉬운 도메인 특화 로직(예: 데이터베이스를 통한 유효성 검사)은 Validator에서 처리하는 방식은 매우 유효한 접근 방식입니다. 특히, 커스텀 예외를 활용해 비즈니스 로직에서 발생할 수 있는 에러를 명확히 처리하는 것은 에러 핸들링 관점에서 봤을 때도 권장됩니다.

직접 구현 시, 주의해야 할 점 중 하나는 Controller 계층에서 이런 Validator를 명시적으로 호출하여 처리할 때, 어떠한 검증 실패나 예외 처리도 충분히 명확하고 사용자 친화적인 피드백으로 전환될 수 있도록 해야 합니다. 즉, 검증 과정에서 발생하는 에러 메시지를 클라이언트가 이해할 수 있는 형태로 적절히 포맷팅하고 반환하는 것이 중요합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변