• 프로젝트를 진행하는 도중, Monolithic 설계를 채택하다보니, 기존에 CUD는 JPA로 구현하고 R은 Mybatis로 구현하였던 방식에서 CRUD를 전부 CRUD로 구현하다보니 의문점이 발생하였습니다.
• 바로 게시글과 회원 사이에 @ManyToOne과 @OneToMany 관계가 존재하다보니 단반형 매핑? 양방향 매핑? 어떤걸 해야하는 지 의문점이 생겼다.

1. ManyToOne 단방향

• 게시글과 회원은 1대다 관계를 가지고 있고, 게시글에 회원id가 필요함으로 게시글이 다과 회원이 일에 해당한다.
• 이 경우에는 게시글에 @ManyToOne을 달아서 1에 해당하는 member_id를 이름으로 설정해준다.
• 다에 해당하는 회원의 경우에는 다른 설정을 해줄 필요가 없다.

• DTO에서는 ManyToOne으로 받아올 Member에서 필요한 memberId만 받아서 사용할 수 있도록 설정하였다.

• 실제 Service 계층에서는 Entity는 해당하는 Member를 담아주고, 그중에 필요한 내용만 setter를 통해서 뽑아서 DTO에 저장하여 넘겼다.

2. @ManyToOne 양방향과 @OneToMany

• 향후 더 구체화 할 예정이지만, 이 방식들은 순환, 참조를 일으켜서 좋지 않다고 한다.
• 양방형 관계나 OneToMany를 쓸 경우, 다른 도메인에서 정보를 가져올 경우 끊임없이 순환 & 참조를 일으킨다.

+) 10/24일 추가사항

@ManyToOne과 @OneToMany 양방향 연관관계 문제점 (순환 & 참조 발생)

• 위는 1대다 관계인 Member와 Board에서 서로 연관 관계가 있는 컬럼을 @ManyToOne과 @OneToMany를 이용해서 연관 관계 매핑을 한 코드

• 위에 보이는 것과 같이 하나를 조회해도 연관되어 잇는 Board와 Memeber가 계속 순환 참조를 일으키는 것을 볼수 있다.
• 양방향 매핑은 무한 순환&참조를 불러 일으킬 수 있음으로, 사용을 지향하고, 단방향 매핑일 경우에만 @ManyToOne을 사용하고, 나머지 경우는 Join을 사용하지 않고, 직접 다른 도메인에 접근해서 사용하는 것이 좋다
  
  

💡 해결방법
1. DTO에 중간객체(VO) 삽입
=>중간객체(VO)를 만들어서 조회를 통해 다른 도메인에서 가져온 정보를 VO에 저장하여 DTO에 배열 형식으로 하면 직접 도메인에 가서 가져올 필요가 없으니 해결 가능
2. Entity에 삽입
=> Entity에 조회해온 값들을 배열 형태로 넣어주면 해결 가능