validation은 request할 때 들어오는 query string이나 request body를 디스패쳐에서 받을 때 또는 컨트롤러에서 응답할 때 데이터가 유효한지 검사하는 것이다.
필터를 이용해 유효성을 검사할 수도 있지만, 응답시 필터를 거치지 않는다는 문제점이 있다. 리플렉션을 통해 컨트롤러의 함수를 실행시키는 디스패쳐는 응답시에도 유효성을 검사할 수 있는 장점이 있다.
사용자가 요청하여 호출되는 컨트롤러 함수를 감싸고있는 디스패쳐는
1.
요청의 method, path를 확인하고 정의된 어노테이션들에 대해 reflection으로 검색한 후, 해당 어노테이션이 붙어있는 컨트롤러 내 함수에 접근한다.
2.
요청의 query string이나 body를 컨트롤러 함수의 파라미터와 비교하여 해당 요청이 유효한지 결정한다.
3.
위 과정 속에서 유효한 요청이 아니라면 BAD REQUEST, 정상이라면 함수에 값을 전달한다.
스프링 내에 구현되어있는 디스패쳐는 요청 주소 매핑, IoC컨테이너 내에 있는 컨트롤러와 rest컨트롤러 리플렉션, 요청 데이터와 함수 매개변수간 유효성을 검사 해주지만, 당연하게도 username의 특수문자 유무같은 사용자의 정의에 따른 유효성은 검사해주지 않는다.
사용자가 직접 AOP를 통해 유효성 검사를 진행하는 공통기능을 만들어 Point-cut하는 방식을 적용하는것이 일반적이다. 프록시 공간 내에서 위치하는 컨트롤러 함수를 유효성검사 공통기능으로 감싸 함수로 값이 들어오는 직전 검사를 진행하거나 함수를 빠져나온 직후 응답에 대해 검사할 수 있다.
스프링의 Validation 라이브러리는 컨트롤러로 받는 파라미터의 NotNull, NotBlank, Size 속성 등 다양한 유효성을 검사하고 Validity result를 컨트롤러 내부로 전달해준다. 사용자는 이 Binding result를 통해 요청이 가져온 데이터의 값 유뮤와 길이 등을 검사하여 잘못된 요청에 대한 응답을 처리할 수 있다.
여기서, Binding result를 받아와 잘못된 요청에 대해 응답하는 기능은 개발자가 사용할 핵심기능이 아닌, 다양한 컨트롤러에 사용될 수 있는 공통기능(Aspect)이다. 스프링이 지원하는 AOP 라이브러리를 이용하여 공통기능으로 묶고 핵심기능에 적용될 수 있도록 적용(Weaving)해주어야 한다.
