오봉이와 함께하는 개발 블로그

Bean Validation - 스프링 적용 ValidationItemControllerV3 코드 수정 @Controller @RequestMapping("/validation/v3/items") @RequiredArgsConstructor @Slf4j public class ValidationItemControllerV3 { private final ItemRepository itemRepository; @GetMapping public String items(Model model) { List items = itemRepository.findAll(); model.addAttribute("items", items); return "validation/v3/items"; } @GetMapping("/{..

Bean Validation - 소개 검증 기능을 지금처럼 매번 코드로 작성하는 것은 상당히 번거롭다. 특히 특정 필드에 대한 검증 로직은 대부분 빈 값인지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다. 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; //... } 이런 검증 로직을 모든 프로젝트에 적용할 수 있게 공통화하고 표준화 한 것이 바로 Bean Validation이다. Bean Validation..

Validator 분리 1 컨트롤러에 있는 검증 로직을 별도로 분리하는 것이 유지보수 측면에서 더 좋을 것이다. 또 분리를 하면 검증 로직을 재사용 할 수도 있다. ItemValidator @Component public class ItemValidator implements Validator { @Override public boolean supports(Class clazz) { return Item.class.isAssignableFrom(clazz); // Item == clazz(파라미터) // Item == subItem(자식 클래스) } @Override public void validate(Object target, Errors errors) { Item item = (Item) targe..

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

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