스프링 MVC 2 - 정리(검증2 - Bean Validation)

정리(검증2 - Bean Validation)

• Bean Validation - 소개
  • 이전처럼 검증 기능을 매번 코드로 작성하는 것은 상당히 번거롭다.
  • 그래서 Bean Validation 에 대해서 알아보고, 간단한 애노테이션으로 검증하는 방법을 알아보았다.
  • 공식 사이트: http://hibernate.org/validator/
  • 공식 메뉴얼: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/
  • 검증 애노테이션 모음: https://docs.jboss.org/hibernate/validator/6.2/reference/en-US/html_single/#validator-defineconstraints-spec
• Bean Validation - 시작
  • build.gradle에 implementation org.springframework.boot:spring-boot-starter-validation 의존관계를 추가했다.
  • Bean Validation은 인터페이스이고, 
  • 구현체로는 hibernate-validator가 있다.
• Bean Validation - 프로젝트 준비 V3
• Bean Validation - 스프링 적용
  • 스프링 부트가 'spring -boot-starter-validation' 라이브러리를 넣으면 자동으로 Bean Validator를 인지하고 스프링에 통합한다. 
  • 스프링 부트는 자동으로 글로벌 Validator로 등록한다.
  • @Valid나 @Validated만 적용하면 된다.
• Bean Validation - 에러 코드
  • Bean Validation은 오류 코드를 기본으로 제공한다.
  • 애노테이션 이름을 그대로 에러코드로 쓴다.
    
    • ex) @NotBlank
    • NotBlank.item.itemName
    • NotBlank.itemName
    • NotBlank.java.lang.String
    • NotBlank
  • 우리는 이것들을 errors.properties 같은곳에 넣어가지고  메시지를 원하는데로 변경할 수 있었다.
• Bean Validation - 오브젝트 오류
  • @ScriptAssert 가 있긴있는데 사용하기 약간 애매하다.
  • 그냥 자바코드로 작성하자.
• Bean Validation - 수정에 적용
• Bean Validation - 한계
  • Bean Validation의 한계가 있었다.
  • 만약, 등록할 때의 요구사항과, 수정할 때의 요구사항이 서로 충돌이 일어날 수 있다.
  • 등록할 때는, quantity가 9999개가 최대인데, 수정할 때는, 마음껏 수정할 수 있게 하자. 라고 정책이 있다면, 
  • 혹은 등록할 때는 id가 없어도 되지만, 수정시에는 Id값이 필수인 경우
  • 이런 경우에는 confilct 난다.
• Bean Validation - groups
  • 위의 문제를 해결하기 위해서 groups라는 기능을 지원한다.
  • 해당 그룹만 검증하는 기능이다.
  • 그런데, 실무에서는 실제로 잘 사용하지는 않는다.
• Form 전송 객체 분리 - 프로젝트 준비 V4
• Form 전송 객체 분리 - 소개
  • 실무에서는 등록할 때의 폼 전송객체, 수정할 때의 폼 전송 객체를 분리한다.
  • groups와 Form 전송 객체 분리가 각각 장단점이 있긴하지만, 복잡해지면 결국 분리해야 한다.
• Form 전송 객체 분리 - 개발
  • item은 순수하게 두고, ItemUpdateForm이랑, ItemSaveForm을 분리했다.
  • Save할 때는 ID가 필요없다. 그래서 ItemSaveForm에는 itemName, price, quantity 3가지만 핏하게 만들었다.
  • Update할 때는 ID가 필요해서 ItemUpdateForm에는 ID, itemName, price, quantity 4가지를 핏하게 만들었다.
  • 대신 이렇게 작성하면, 컨트롤러의 코드가 조금더 길어진다.
  • 왜냐하면, addItem에서는 ItemSaveForm객체를 받기때문에 검증을 위해서 필수적으로 item객체에 담아주는 컨버팅 로직 코드를 추가해야되고,
  • edit에서는 ItemUpdateForm 객체를 받기 때문에 검증을 위해서 필수적으로 item객체에 담아주는 컨버팅 로직 코드를 추가해야한다.
  • 컨버팅 하는 로직을 생략하고싶어서 어찌저찌하다보면 오히려 코드가 더 난잡해질 수 있다. 컨버팅 로직을 귀찮아하지 말자.
  • 정말 간단한 경우에는 addItem과 edit을 합쳐서 사용하는 방법도 고려해보면 좋지만, 분리하는게 서비스 확장성 측면에서는 더 좋다.
• Bean Validation - HTTP 메시지 컨버터
  • Bean Validation은 ModelAttribute뿐만 아니라, HttpMessageConverter가 동작하는 @RequestBody에도 적용을 할 수 있다. 
  • @ModelAttribute와 @RequestBody의 차이는,
  • @ModelAttribute는 field 하나하나를 세밀하게 적용한다.
  • @RequestBody는 JSON이 HttpMessageConverter가 정상적으로 동작을 해서 어쨋든 JSON이 객체로 변경이 되야 검증을 하던 뭐라도 할수 있다. 만약 JSON이 객체로 변경되지 않으면 그다음단계로 못넘어간다.
  • @ModelAttribute와 @RequestBody는 이러한 차이점이 있다.
• Bean Validation - 정리