개발자되기 프로젝트

1. Bean Validation 의존관계 추가 build.gradle implementation 'org.springframework.boot:spring-boot-starter-validation' 추가되는 라이브러리 jakarta.validation-api : Bean Validation 인터페이스 hibernate-validator : 구현체 2. Bean Validation 사용 import lombok.Data; import org.hibernate.validator.constraints.Range; import javax.validation.constraints.Max; import javax.validation.constraints.NotBlank; import javax.validatio..

검증 기능을 지금처럼 매번 코드로 작성하는 것은 귀찮음... 특히 특정 필드에 대한 검증 로직은 대부분 빈 값인지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적 로직임. ??? : 그러면 @Annotation으로 처리해보자. public class Item { private Long id; @NotBlank private String itemName; @NotNull @Range(min = 1000, max = 1000000) private Integer price; @NotNull @Max(9999) private Integer quantity; //... } 1. Bean Validation 먼저 Bean Validation은 특정한 구현체가 아니라 Bean Validation 2.0(JSR..

스프링이 Validator 인터페이스를 별도로 제공하는 이유는 체계적으로 검증 기능을 도입하기 위해서임. 그런데 앞에서는 검증기를 직접 불러서 사용했음. 그런데 Validator 인터페이스를 사용해서 검증기를 만들면 스프링의 추가적인 도움을 받을 수 있음. 1. WebDataBinder를 통해 사용 WebDataBinder 는 스프링의 파라미터 바인딩의 역할을 해주고, 검증 기능도 내부에 포함한다. 2. WebDataBinder 적용 2.1 Controller @InitBinder 적용, init() 해당 메서드에 WebDataBinder를 넘겨주고, WebDataBinder에 validator를 넣어준다. 이렇게 되면 Controller가 호출될 때마다 WebDataBinder를 생성한다. 이렇게 We..

1. Validator 현재 Controller가 너무 많은 역할을 가지고 있다. 검증 부분을 따로 분리하자 Spring은 검증을 체계적으로 제공하기 위해 Validator.interface 제공 public interface Validator { boolean supports(Class clazz); void validate(Object target, Errors errors); } supports() {} : 해당 검증기를 지원하는 여부 확인(뒤에서 설명) validate(Object target, Errors errors) : 검증 대상 객체와 BindingResult 2. ItemValidator supports() 넘어온 타입이 검증하기 위한 타입인지 판단. 구현시 return에 isAssign..

1. Spring이 직접 만든 오류 메시지 처리 검증 오류 코드는 크게 두 가지 개발자가 직접 설정한 오류 코드 -> rejectValue()를 직접 호출함 Spring이 직접 검증 오류에 추가한 경우 -> 바인딩 오류(주로 타입종류 맞지 않은 경우) 2. 동작 방식 price필드에 "A"를 입력하자. log를 보면 BindingResult에서 FieldError를 확인할 수 있다. Field error in object 'item' on field 'price': rejected value [qqq]; 또한 다음과 같이 Message Codes가 생성된다. codes[typeMismatch.item.price,typeMismatch.price,typeMismatch.java.lang.Integer,ty..

1. 오류 코드 관리 전략 핵심은 구체적인 것에서! 덜 구체적인 것으로! MessageCodesResolver 는 required.item.itemName 처럼 구체적인 것을 먼저 만들어주고, required 처럼 덜 구체적인 것을 가장 나중에 만든다. 이렇게 하면 앞서 말한 것 처럼 메시지와 관련된 공통 전략을 편리하게 도입할 수 있다. 복잡하게 사용하는 이유?? 모든 오류 코드에 대해서 메시지를 각각 다 정의하면 개발자 입장에서 관리하기 힘들다. 크게 중요하지 않은 메시지는 범용성 있는 requried 같은 메시지로 끝내고, 정말 중요한 메시지는 꼭 필요할 때 구체적으로 적어서 사용하는 방식이 더 효과적 2. 메시지 추가 #required.item.itemName=상품 이름은 필수입니다. #range..

1. MessageCodesResolver 검증 오류 코드로 메시지 코드들을 생성한다. MessageCodesResolver 인터페이스이고 DefaultMessageCodesResolver 는 기본 구현체이다. 주로 다음과 함께 사용 ObjectError , FieldError 2. Test - object errorCode="required"인 메시지를 찾아보자. @Test void messageCodesResolverObject(){ String[] messageCodes = codesResolver.resolveMessageCodes("required", "item"); for (String messageCode : messageCodes) { System.out.println("messageCod..

???오류 코드를 얼마나 자세히 만들어야 할까 오류 코드를 만들 때 다음과 같이 자세히 만들 수도 있고, required.item.itemName : 상품 이름은 필수 입니다. range.item.price : 상품의 가격 범위 오류 입니다. 또는 다음과 같이 단순하게 만들 수도 있다. required : 필수 값 입니다. range : 범위 오류 입니다. 단순하게 만들면 범용성이 좋아서 여러곳에서 사용할 수 있지만, 메시지를 세밀하게 작성하기 어렵다. 반대로 너무 자세하게 만들면 범용성이 떨어진다. 가장 좋은 방법은 범용성으로 사용하다가, 세밀하게 작성해야 하는 경우에는 세밀한 내용이 적용되도록 메시지에 단계를 두는 방법이 좋음. 예를 들어서 required 라고 오류 코드를 사용한다고 가정해보자. 다..