[JSCODE] 4회차

🎯 목표

• 유효성 검사
• 예외 처리

✏️ 내용

1. 유효성 검사

게시글의 제목과 내용에 대한 유효성 검사를 위한 애노테이션을 걸어주었다.

@NotBlank(message = "제목은 공백 없이 1글자 이상 15글자 이하여야 합니다.")
@Size(min = 1, max = 15, message = "제목은 공백 없이 1글자 이상 15글자 이하여야 합니다.")
private String title;

@NotEmpty(message = "내용은 1글자 이상 1000글자 이하여야 합니다.")
@Size(min = 1, max = 1000, message = "내용은 1글자 이상 1000글자 이하여야 합니다.")
private String content;

이 과정에서 @NotNull, @NotBlank, @NotEmpty 차이도 알게 되었다.
간단하게 정리하자면 다음과 같다.

• @NotNull: null 허용 X
• @NotEmpty: null, "" 허용 X
• @NotBlank: null, "", " "(공백) 허용 X

2. 유효성 검사 위치

validation 애노테이션을 엔티티와 dto 둘 중에 어디에 붙일까 고민하다가 dto에 붙여주었는데, 그 이유는 다음과 같다.

• 데이터를 전달하는 dto에서 유효성 검사를 수행하면, 클라이언트나 다른 계층으로 검증된 데이터를 전달할 수 있다.
• 엔티티에 유효성 검사 로직을 넣지 않아도 됨으로써 유지보수성을 향상시킬 수 있다.

3. @Column을 굳이?

dto에 validation 애노테이션을 붙여주다가 문득 @Column(length = 15)같은 컬럼 매핑 애노테이션도 붙여줘야 하는지 궁금했다.

이미 데이터의 유효성을 검사한 다음에 DB로 넘겨주는데 굳이 @Column을 통해서 제약 조건을 걸어줄 필요가 있나 싶었고, 멘토님께 이에 대한 질문을 드렸다.

돌아온 대답은 "붙여주어야 한다"였다.
정확히는 DB에 제약조건을 직접 걸어줬다면 엔티티에도 똑같이 명시해줘야 한다고 하셨다.

그 이유는 여러가지가 있었는데 그 중 가장 와닿은 것은 가독성을 높여준다는 점과 개발자의 실수를 방지할 수 있다는 점이었다.

4. 예외 처리

예외 처리를 어떤 방식으로 진행하는지 감이 안 잡혀서 지인에게 도움을 요청했고, @ExceptionHandler와 @RestControllerAdvice를 통해 모든 예외를 한 곳에서 공통으로 처리하는 전략에 대해서 알게 되었다.

예제 코드를 참고하여 구현하기만 해서, 해당 개념에 대해 깊게 학습하고 스스로 다시 한 번 구현할 예정이다.

💬 회고

요청한 데이터의 유효성 검사는 너무나 중요하다.
하지만 어떤 방식으로 검사하고, 예외까지 처리하는지 잘 몰라서 배워야지 배워야지 하면서 미루게 되었다.
그러다가 이번 기회에 유효성 검사와 예외 처리에 대한 전체적인 방법을 알게 되었고, 이제 스스로 할만할 것 같다는 생각이 든다.

부족한 부분 & 개선 방향

• 검색 키워드에 대한 유효성 검사
  -> String 타입의 키워드를 검사하는게 아니라 @RequestBody에 PostSearch 클래스를 직접 담아 처리할 예정이다.