[TIL] @Data vs @Getter, @Setter | Building Result란? | CreatedAt UpdatedAt null 해결

 

오늘의 목표 - My Select Shop 과제 완료하기

 

과제가 하루 밀려 여유가 더 생겼지만 오늘 안에 꼭! 끝내고 싶어서 완성하였다.

 

과제를 하면서 궁금했던 부분에 대해 정리해보려 한다.

 

 

@Data대신 @Getter @Setter를 쓰는 이유

 

강의 자료를 보면 모든 Dto가 @Getter와 @Setter를 사용한다.

 

여기서 의문이 들었던 점

@Data를 사용하면 @Getter와 @Setter의 기능을 모두 사용하면서 코드가 간결해지는데 왜 @Data를 사용하지 않는 걸까?

 

찾아보니, @Data는 @Getter @Setter 뿐만 아니라 @EqualsAndHashCode와 @RequiredArgsConstructor @ToString을 포함하고 있어서 지양하는 편이 좋다고 한다. 많은 기능을 한 번에 사용하는 만큼 사이드 이펙트도 무시할 수 없다.

(@EqualsAndHashCode는 equals와 hashcode 메서드를 자동 생성해 주는 어노테이션이다.)

 

아래 블로그에 잘 정리되어 있다

https://roopredev.tistory.com/14

 

 

BindingResult란?

 

스프링에서 제공하는 검증오류 보관 객체

검증할 필드가 있는 DTO에 @Valid를 붙여서 사용한다.

public String signup(@Valid SignupRequestDto requestDto, BindingResult bindingResult){
    // Validation 예외처리
    List<FieldError> fieldErrors = bindingResult.getFieldErrors();
    if(fieldErrors.size() > 0) {
        for (FieldError fieldError : bindingResult.getFieldErrors()) {
            log.error(fieldError.getField() + " 필드 : " + fieldError.getDefaultMessage());
        }
        return "redirect:/api/user/signup";
    }

    userService.signup(requestDto);

    return "redirect:/";
}

 

 

 

CreatedAt UpdatedAt null 오류 

 

다른 데이터는 잘 들어가는데 시간만 null이 들어갔다.

시간 자동 변경이 가능하도록 하는 어노테이션인 @EnableJpaAuditing을 application 클래스에 추가해서 해결했다.