유효성 검증이라는 뜻으로 해석할 수 있다. 주로 사용자 또는 서버의 요청(http requeset)내용에서 잘못된 내용이 있는지 확인하는 단계를 말한다.
학문적으로는 여러 단계가 있지만 실제로 개발할때 챙겨야 하는 검증은 크게 두가지로 나뉜다.
public class MemberCreateRequest{
@NotBlank(message="이름을 말해주세요.")
@Size(max = 64,message="이름의 최대 길이는 64자 입니다.")
private String name;
@Min(0,"나이는 0 보다 커야합니다.")
private int age;
@Email("이메일 형식이 잘못되었습니다.")
private int email;
}
위처럼 요청 dto에 어노테이션으로 명시 후 아래처럼 @Valid 어노테이션을 해당 @RequestBody에 달게 되면,Java Bean Validation을 수행한 후 문제가 없을때만 메서드 내부로 진입이 된다.
만약 검증이 실패하면: MethodArgumentNotVaildException이 발생한다.
@PostMapping(value= "/member")
public MemberCreationResponse CreateMember(
@Valid @RequestBody final MemberCreateRequest memberCreaionRequest){
//member creation logic here...
}
2.Spring validator 인터페이스 구현을 통한 validation
public class Person{
private String name;
private int age;
// the usual getters and setters
}
위처럼 Person 이라는 javaBean 객체가 있을 때, 아래는 해당 인스턴스에서만 활용되는 Validator이다.
인터페이스에 있는 두개의 메서드는 아래와 같은 역할을 한다.
public class PersonValidator implements Validator{
public boolean supports(Class.clazz){
return Person.class.equals(clazz);
}
public void validate(Object obj,Errors e){
ValidationUtils.rejectIfEmpty(e,"name","name.empty");
Person p = (Person) obj;
if(p.getAge()<0){
e.rejectValue("age","negativevalue");
}else if(p.getAge() > 110){
e.rejectValue("age","too.darn.old");
}
}
}
validation이 너무 여러 곳에 흩어져 있으면 테스트 및 유지보수성이 떨어진다.
중복된 검증
: 정책 변경시에 모든 중복 코드를 수정해야 함.
다른 검증
: 여러 곳에서 다른 정책을 따르는 검증이 수행될 수 있음.
가능한 validation은 로직 초기에 수행 후 실패 시에는 exception을 던지는 편이 처리하기 편리함.
실무 활용 패턴
요청 dto에서 Java Bean Validation으로 단순 데이터(유무,범위,형식)을 1차 검증
로직 초기에 2차 비즈니스 검증 수행 후 실패 시에는 Custom Exception(ErrorCode,ErrorMessage를 입력)해서 예외를 던지도록 하고 예외처리하여 응답 생성
Spring validator의 장단점
장점: Java Bean Validator에 비해 조금 더 복잡한 검증 가능
단점: Validation을 수행하는 코드 찾기가(상대적으로) 어렵다.
, 완전히 데이터만 검증하는 것이 아니기 때문에 일부 비즈니스적인 검증이 들어가는 경우가 있음
-> 이 경우 비즈니스 검증 로직이 여러 군데로 흩어지기 때문에 잘못된 검증(중복 검증, 다른 정책을 따르는 검증)을 수행할 가능성이 높아짐
팀 내에서 사용하는 검증방법을 사용하는게 가장 좋다!!