Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2주차 과제 완료 #10

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

2주차 과제 완료 #10

wants to merge 1 commit into from

Conversation

airoca
Copy link
Collaborator

@airoca airoca commented Oct 25, 2024

Summary

Validation

  • Controller, Service 검증 분리
    제목, 내용이 비어있는 요청의 경우 Controller 부분에서 검증을 수행하고, 기타 비즈니스 로직과 관련된 검증은 Service에서 수행하였다. 기본 입력값 검증은 Controller에서 처리하고, 비즈니스 로직과 관련된 검증은 Service에서 수행하도록 역할 분리.

  • 필드 유효성 검증
    필드의 "유효성"은 HttpMessageNotReadableException을 통해 검증하였다. (타입 에러 등)

  • 제목 유일성 검증
    제목의 유일성 검증의 경우 Service에서 검증하는 대신 Entity의 title 필드를 unique로 만들어줬다. (Race Condition으로 인한 중복값 저장 우려) 하지만 이 경우 데이터베이스 부담이 증가하고(데이터베이스가 중복 오류를 감지하고 롤백 처리하는 데 리소스를 사용), 검증이 데이터베이스 의존적이게 된다는 것에 문제점을 느꼈다. 결과적으로 Entity의 title 필드를 unique로 만듦과 동시에, Service에서도 중복값 검증을 수행하는 방식으로 결정하였다.

Asynchronous

  • 기존 코드에서는 List를 통해 일기 목록을 반환했지만, 이를 Flux로 수정하였다. 일기 목록의 경우 날짜가 지날수록 데이터의 양이 많아지기 때문에, 비동기 처리의 필요성을 느꼈다.

  • 이러한 변경을 통해 서버에서는 일기 목록을 반환하는 동안 비동기적으로 다른 작업을 수행할 수 있고, 이를 통해 통신 대기 시간 감소, 다수의 요청 처리에 대한 용이성을 얻을 수 있다.

@airoca
Copy link
Collaborator Author

airoca commented Oct 25, 2024

한 명의 사용자가 독립된 하나의 일기 목록을 관리하는 애플리케이션이라면, 제목 유일성에서 고려한 Race Condition이 의미가 없을 수 있습니다. 그러나 기획에 명시되어 있지 않은 부분이기에, 여러 사용자가 하나의 일기 목록에 접근하는 상황도 가정하였습니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant