스프링 Ch 6-1 validation - 패스트캠퍼스 챌린지 8일차

드디어 다음 챕터입니다.

Object 에 어노테이션을 붙이던, newtype 패턴으로 검증 로직을 감싸던 데이터 객체의 검증 로직을 적절히 비즈니스 로직과 분리하는 것은 필수입니다. 아니면 하나하나 그걸 다 손수 if else 같은거로 검증하고 있어야 하니까요. 프로그래머가 제일 싫어하는 게 노가다 아니겠습니까?

Spring 에서는 데이터 객체에 어노테이션을 붙여서 검증 방식을 결정합니다. 꽤나 풍부한 내장 검증 로직이 있어서 있는 거만 가져다써도 웬만한 사례에선 불편함이 없을 것 같아보이네요. 1강에서는 아직 커스텀 검증 로직을 만드는 방법은 나오지 않았어서 검증 로직이 어디에 들어가는지는 나오지 않았는데요, 아마 같은 클래스이거나 다른 클래스에 별도로 만들거나 또 어노테이션을 만들거나 그러지 않을까요?

눈에 띄는 건 역시 @Valid 라는 새로운 어노테이션입니다. 핸들러의 패러미터에도 잊지 않고 어노테이션을 붙여주는 걸 잊지 말아야겠네요. 그리고 자세한 오류 정보가 필요하다면 BindingResult 클래스를 패러미터로 넣어야 합니다. 이거 내부 로직은 어느 단계에서 400 컷이 나는지 궁금하네요. 함수 본문은 돌아가는 거 같던데... 반환값을 무시하려나요? 다음에 찾아봐야겠습니다. (다음에 찾아봐야지만 벌써 두 개...)

• 검증 어노테이션
  • @Size - 문자열 길이
  • @NotNull @NotEmpty @NotBlank
  • @Past @PastOrPresent @Future @FutureOrPresent
  • @Pattern - 정규식
  • @Max @Min
  • @Email 등 이미 있는 세트
  • @AssertTrue / AssertFalse (다음 강의)
• 핸들러에 붙이는 어노테이션
  • @Valid
  • 패러미터 BindingResult

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.
패스트캠퍼스: https://bit.ly/37BpXiC

#패스트캠퍼스 #패캠챌린지 #직장인인강 #직장인자기계발 #패스트캠퍼스후기 #한번에끝내는JavaSpring웹개발마스터초격차패키지Online

여기까지 와서 이러고 있는 내가 레전드다... 금요일엔 주사 맞고도 해야합니다 메우...