오늘의 이슈
이슈를 설명하기 전 주요 정보
- Match 도메인은 매치를 등록하는 도메인이다.
- Apply도메인은 Post되어있는 Match에 신청할 수 있는 도메인이다.
- Apply는 Team_Apply, League_Apply, Match_Apply가 있으며 각각 Team_List, League_List, Match_List 와 일대다의 연관관계를 맺고 있다.
- Match_List 도메인은 Match에 참여하는 A팀과 B팀의 정보를 담는 도메인이다.
Match는 일반 매치와 리그 매치를 post한다.
일반 매치의 flow는 다음과 같다.
- Match를 만든 A팀은 Home 팀이 된다.
- Match를 Post과 동시에 Match_List가 Post된다.
- Match_List에 A팀의 정보가 삽입된다.
- B팀은 Apply를 통해 A팀이 생성한 Match에 신청할 수 있다.
- A팀은 Apply에서 자신이 원하는 팀을 고른다.
- Match_List에 B팀의 정보가 삽입된다.
리그 매치의 flow는 다음과 같다.
- A팀 또는 B팀의 Manager권한을 가지고 있는 유저가 League_Match를 Post한다.
- Match_List에 A팀과 B팀의 정보가 삽입된다.
- 리그 정보를 가져와야 하기 때문에 League_List의 정보를 가져온다.
문제는 2-1에서 발생했다. 그 이유는 Match와 Apply, Apply와 League_List, League_List와 Match가 일대대의 관계를 맺고 있기 때문이다.
Apply가 다른 flow에서 League_List와 일대다의 관계를 맺고 있기 때문에 Match에 League_List 정보를 넘겨 받기 위해 League_List를 인터페이스로 주입 받게 된다면 순환참조가 발생하는 것이다.
해결방안
순환참조를 해결하는 방법은 순환을 끊는 것이다.
A-B, B-C가 서로 연결되어있는 상황에서 C-A를 이어준다면 A-B-C는 순환한다.
하지만 D를 새로 만들어 D와 C를 연결한다면 A-B-C가 연결되어 있지만 D-C는 A-B-C와 순환하는 구조는 아니게 된다.
따라서 기존 방식이었던 Match 도메인에서 일반 매치와 리그매치를 컨트롤하는 방식이 아닌 일반 매치 도메인과 리그 매치 도메인을 분리하고 리그매치에서만 League_List의 정보를 가져온다면 해결할 수 있다.
주의사항
순환참조는 잘못된 설계에 의해서 발생한다. 따라서 내가 구현한 Flow가 복잡하게 형성되어있지 않는지, 또는 연관관계를 잘못 설정하지 않았는지 확인해야한다.
'Project > Whistle(축구 매칭 웹 서비스)' 카테고리의 다른 글
Whistle, 휘슬 프로젝트 ERD 설명 (4) | 2024.06.25 |
---|---|
spring security apply() deprecated 이슈 트러블 슈팅 (0) | 2024.06.11 |
Spring Security 마이그레이션 중 발생한 에러 해결 (1) | 2024.05.22 |
[ whistle ] 불확실한 변수명과 클래스명의 위험성 (2) | 2023.12.05 |
[ Whistle ] Match 테이블과 Team의 다대다 연관 관계 필요성에 관련한 문제 (0) | 2023.09.14 |
오늘의 이슈
이슈를 설명하기 전 주요 정보
- Match 도메인은 매치를 등록하는 도메인이다.
- Apply도메인은 Post되어있는 Match에 신청할 수 있는 도메인이다.
- Apply는 Team_Apply, League_Apply, Match_Apply가 있으며 각각 Team_List, League_List, Match_List 와 일대다의 연관관계를 맺고 있다.
- Match_List 도메인은 Match에 참여하는 A팀과 B팀의 정보를 담는 도메인이다.
Match는 일반 매치와 리그 매치를 post한다.
일반 매치의 flow는 다음과 같다.
- Match를 만든 A팀은 Home 팀이 된다.
- Match를 Post과 동시에 Match_List가 Post된다.
- Match_List에 A팀의 정보가 삽입된다.
- B팀은 Apply를 통해 A팀이 생성한 Match에 신청할 수 있다.
- A팀은 Apply에서 자신이 원하는 팀을 고른다.
- Match_List에 B팀의 정보가 삽입된다.
리그 매치의 flow는 다음과 같다.
- A팀 또는 B팀의 Manager권한을 가지고 있는 유저가 League_Match를 Post한다.
- Match_List에 A팀과 B팀의 정보가 삽입된다.
- 리그 정보를 가져와야 하기 때문에 League_List의 정보를 가져온다.
문제는 2-1에서 발생했다. 그 이유는 Match와 Apply, Apply와 League_List, League_List와 Match가 일대대의 관계를 맺고 있기 때문이다.
Apply가 다른 flow에서 League_List와 일대다의 관계를 맺고 있기 때문에 Match에 League_List 정보를 넘겨 받기 위해 League_List를 인터페이스로 주입 받게 된다면 순환참조가 발생하는 것이다.
해결방안
순환참조를 해결하는 방법은 순환을 끊는 것이다.
A-B, B-C가 서로 연결되어있는 상황에서 C-A를 이어준다면 A-B-C는 순환한다.
하지만 D를 새로 만들어 D와 C를 연결한다면 A-B-C가 연결되어 있지만 D-C는 A-B-C와 순환하는 구조는 아니게 된다.
따라서 기존 방식이었던 Match 도메인에서 일반 매치와 리그매치를 컨트롤하는 방식이 아닌 일반 매치 도메인과 리그 매치 도메인을 분리하고 리그매치에서만 League_List의 정보를 가져온다면 해결할 수 있다.
주의사항
순환참조는 잘못된 설계에 의해서 발생한다. 따라서 내가 구현한 Flow가 복잡하게 형성되어있지 않는지, 또는 연관관계를 잘못 설정하지 않았는지 확인해야한다.
'Project > Whistle(축구 매칭 웹 서비스)' 카테고리의 다른 글
Whistle, 휘슬 프로젝트 ERD 설명 (4) | 2024.06.25 |
---|---|
spring security apply() deprecated 이슈 트러블 슈팅 (0) | 2024.06.11 |
Spring Security 마이그레이션 중 발생한 에러 해결 (1) | 2024.05.22 |
[ whistle ] 불확실한 변수명과 클래스명의 위험성 (2) | 2023.12.05 |
[ Whistle ] Match 테이블과 Team의 다대다 연관 관계 필요성에 관련한 문제 (0) | 2023.09.14 |