Add notification agreement field in user-info-dto #131
Conversation
| @@ -34,6 +35,7 @@ public class UserService implements UserDetailsService { | |||
| private final UserRepository userRepository; | |||
| private final PasswordEncoder passwordEncoder; | |||
| private final OAuthService oAuthService; | |||
| private final DeviceTokenRepository deviceTokenRepository; | |||
There was a problem hiding this comment.
순환참조 문제(UserService와 DevicetokenService)가 발생해서 DeviceRepository를 두번 의존성 주입을 했습니다.
스프링 컨테이너는 싱글톤 범위로 빈을 관리하므로, DeviceTokenRepository는 하나의 인스턴스만 생성되고, 그 인스턴스가 DeviceTokenService 및 UserService에 주입된다고 하긴 해서 우선 이렇게 진행하긴 했는데, 이 방법 말고 어떻게 해결할 수 있을지 궁금합니다. (@Lazy 어노테이션 등의 방법 말고 설계를 처음부터 다시해야 하는지 등의 방법이 궁금합니다.)
There was a problem hiding this comment.
저도 지난 번 순환 참조 문제가 발생했던 적이 있었습니다.
순환 참조 문제를 해결하기 가장 좋은 방법은 처음부터 잘 설계하자가 맞습니다. 하지만 이렇게 할 경우에는 작업 시간이 늘어나게 될 것 입니다.
@Lazy 어노테이션 또한 권장하는 방법은 아니라고 합니다. @Lazy 어노테이션은 빈의 생성 시기를 늦추는 것이지 근본적으로 순환 참조를 해결할 수는 없기 때문에(저는 임시 방편 정도로 생각하고 있습니다), 순환 참조가 발생하였을 때 이를 파악하는 시기를 늦출 뿐이라고 합니다.
예전에 제가 순환 참조를 해결하면서 작성했던 문서가 있는데 가볍게 읽어보시면 좋을 것 같습니다!
현재 구현해주신 코드가 개발 진행 속도를 고려한다면 어쩔 수 없는 선택이라고 생각합니다.
| @@ -11,14 +11,18 @@ | |||
| @Getter | |||
| @JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class) | |||
| public class UserInfoResponseDto { | |||
| private Long id; | |||
There was a problem hiding this comment.
P5 : id를 Dto에 추가하신 이유가 궁금합니다.
There was a problem hiding this comment.
클라이언트에서 요청하여 추가하였습니다. 슬랙 스레드에 댓글로 언급되어 있어서 확인 못 하셨나봅니다!
PR Type
Motivation
유효기간알림, 기프티콘 등록 성공/실패 여부 알림 등 정보성 알림에 대한 수신 동의 관리 필요성 대두
로 관리하기로 클라이언트와 협의함
Problem Solving
To Reviewer
정보성 알림과 광고성 알림 법률의 차이가 있다는 것을 파악했고, GH-301에 관련 자료 첨부하였습니다.