Spring
스프링 MVC 2 - 정리(검증1 - Validation)
스프링 MVC 2 - 정리(검증1 - Validation)
2022.09.01정리(검증1 - Validation) 검증 요구사항 클라이언트 검증은 사용성이 좋으나 신뢰할 수 없어서 서버 검증과 섞어서 써야함. 타입검증 필드 검증 특정 필드의 범위를 넘어서는 검증 프로젝트 설정 V1 검증 직접 처리 - 소개 성공로직 실패로직 - 실패하게되면 컨트롤러에서 다시 폼을 보여준다. 검증 직접 처리 - 개발 프로젝트 준비 V2 BindingResult1 BindingResult FieldError ObjectError BindingResult2 BindingResult가 있으면 오류정보(FieldError)를 BindingResult에 담아서 컨트롤러를 정상 호출한다. BindingResult에 검증 오류를 적용하는 3가지 방법 @ModelAttribute의 객체에 타입 오류 등으로 바인딩..
스프링 MVC 2 - Validator 분리2
스프링 MVC 2 - Validator 분리2
2022.09.01Validator 분리2 스프링이 Validator 인터페이스를 별도로 제공하는 이유는 체계적으로 검증 기능을 도입하기 위해서다. 그런데 앞에서는 검증기를 직접 불러서 사용했고, 이렇게 사용해도 된다. 그런데 Validator 인터페이스를 사용해서 검증기를 만들면 스프링의 추가적인 도움을 받을 수 있다. WebDataBinder를 통해서 사용하기 WebDataBinder는 스프링의 파라미터 바인딩의 역할을 해주고 검증 기능도 내부에 포함한다. ValidationItemControllerV2에 다음 코드를 추가하자 이렇게 WebDataBinder에 검증기를 추가하면 해당 컨트롤러에서는 검증기를 자동으로 적용할 수 있다. @InitBinder → 해당 컨트롤러에만 영향을 준다. 글로벌 설정은 별도로 해야한다..
스프링 MVC 2 - Validator 분리1
스프링 MVC 2 - Validator 분리1
2022.08.31Validator 분리1 목표 복잡한 검증 로직을 별도로 분리하자. 컨트롤러에서 검증 로직이 차지하는 부분은 매우 크다. 이런 경우 별도의 클래스로 역할을 분리하는 것이 좋다. 그리고 이렇게 분리한 검증 로직을 재사용 할 수도 있다. ItemValidator를 만들자. 스프링은 검증을 체계적으로 제공하기 위해 다음 인터페이스를 제공한다. supports() {} : 해당 검증기를 지원하는 여부 확인(뒤에서 설명) validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult ItemValidator 직접 호출하기 ValidationItemControllerV2 - addItemV5() 코드 변경 addItemV4()의 @PostMapping 부분 주석..
스프링 MVC 2 - 오류 코드와 메시지 처리6
스프링 MVC 2 - 오류 코드와 메시지 처리6
2022.08.31오류 코드와 메시지 처리6 스프링이 직접 만든 오류 메시지 처리 검증 오류 코드는 다음과 같이 2가지로 나눌 수 있다. 개발자가 직접 설정한 오류 코드 → rejectValue()를 직접 호출 스프링이 직접 검증 오류에 추가한 경우(주로 타입 정보가 맞지 않음) 지금까지 학습한 메시지 코드 전략의 강점을 지금부터 확인해보자. price 필드에 문자 "A"를 입력해보자. 로그를 확인해보면 BindingResult에 FieldError가 담겨있고, 다음과 같은 메시지 코드들이 생성된 것을 확인할 수 있다. codes[typeMismatch.item.price,typeMismatch.price,typeMismatch.java.lang.Integer,typ eMismatch] 다음과 같이 4가지 메시지 코드가 ..
스프링 MVC 2 - 오류 코드와 메시지 처리5
스프링 MVC 2 - 오류 코드와 메시지 처리5
2022.08.31오류 코드와 메시지 처리5 오류 코드 관리 전략 핵심은 구체적인 것에서! 덜 구체적인 것으로! MessageCodesResolver는 required.item.itemName 처럼 구체적인 것을 먼저 만들어주고, required처럼 덜 구체적인 것을 가장 나중에 만든다. 이렇게 하면 앞서 말한 것 처럼 메시지와 관련된 공통 전략을 편리하게 도입할 수 있다. 왜 이렇게 복잡하게 사용하는가? 모든 오류 코드에 대해서 메시지를 각각 다 정의하면 개발자 입장에서 관리하기 너무 힘들다. 크게 중요하지 않은 메시지는 범용성 있는 required 같은 메시지로 끝내고, 정말 중요한 메시지는 꼭 필요할 때 구체적으로 적어서 사용하는 방식이 더 효과적이다. 이제 우리 애플리케이션에 이런 오류 코드 전략을 도입해보자. 우..
스프링 MVC 2 - 오류 코드와 메시지 처리4
스프링 MVC 2 - 오류 코드와 메시지 처리4
2022.08.30오류 코드와 메시지 처리4 우선 테스트 코드로 MessageCodesResolver를 알아보자. MessageCodesResolverTest MessageCodesResolver 검증 오류 코드로 메시지 코드들을 생성한다. MessageCodesResolver 인터페이스이고 DefaultMessageCodesResolver는 기본 구현체이다. 주로 다음과 함께 사용 ObjectError, FieldError DefaultMessageCodesResolver의 기본 메시지 생성 규칙 객체 오류 객체 오류의 경우 다음 순서로 2가지 생성 1.: code + "." + object name 2.: code 예) 오류 코드: required, object name: item 1.: required.item 2...