검증 처리 / BindingResult

검증이 왜 필요한가

웹 서비스는 폼 입력시 오류가 발생하면, 고객이
입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 친절하게 알려주어야 한다

컨트롤러의 중요한 역할중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 

클라이언트 검증은 조작할 수 있으므로 보안에 취약하다.
서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다.
둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수이다.
API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 함.

 

검증의 방법

스프링에서 검증은 Errors와 BindingResult를 사용한다.

BindingResult 방법이 쉬워 이 방법을 주로 쓰겠지만 Errors 를 상속받는 부모-자식 관계이다.

 

 

BindingResult

BindingResult  파라미터의 위치는 
@ModelAttribute 다음에 와야 한다.

=> 검증하기 위한 객체의 뒤에 오는 것이 해당 객체를 검증하겠다는 것을 의미한다.

바인딩리설트에서 FieldError는 필드의 에러를 검증한다.
=> 파라미터는 객체, 필드명, 에러메세지 이다.

ObjectError는 글로벌 에러를 검증한다.
=> 파라미터는 객체와 에러메세지이다.

 

 

타임리프에서 필드 에러 처리하기

th:field와 바인딩 된 필드가 에러가 있다면 th:errorCalss가 그걸 감지하고 해당 css를
적용시킨다.

 

글로벌 에러 처리

글로벌 에러

 

BindingResult 는 Model에 자동으로 포함된다

BindingResult , FieldError , ObjectError 를 사용해서 오류 메시지를 처리하는 방법을 알아보았다.
그런데 위 코드의 문제점은 오류가 발생하는 경우 고객이 입력한 내용이 모두 사라진다.

 

입력한 데이터를 보존하자

 

FieldError 는 두 가지 생성자를 제공한다

 

파라미터 목록 (순서대로)

• objectName : 오류가 발생한 객체 이름
• field : 오류 필드
• rejectedValue : 사용자가 입력한 값(거절된 값)
• bindingFailure : 타입 오류 같은 바인딩 실패인지, 검증 실패인지 구분 값
• codes : 메시지 코드
• arguments : 메시지에서 사용하는 인자
• defaultMessage : 기본 오류 메시지

여기서 rejectedValue 가 바로 오류 발생시 사용자 입력 값을 저장하는 필드다.
bindingFailure 는 타입 오류 같은 바인딩이 실패했는지 여부를 적어주면 된다. 여기서는 바인딩이
실패한 것은 아니기 때문에 false 를 사용한다.

 

오류 메세지 다양화

 

properties에 다양한 오류 메세지들을 저장하여 해당 메세지들을 불러와 사용할 수 있다.

 

애플리케이션 프로퍼티에 에러 프로퍼티를 사용하겠다는 것을 명시해주자

 

이제 FieldError와 ObjectError에서 기본 메세지말고 properties에서 작성한 메세지를 가져오면 된다.

 

codes와 arguments 파라미터에 메세지와 해당 메세지에 필요한 파라미터를 설정해줄 수 있다.

 

메세지의 경우 String 배열

파라미터의 경우 Object 배열을 사용한다.