연관관계의 주인

 

 

연관관계의 주인을 명확히 알아야 클래스 설계를 마무리할 수 있다. 

연관관계의 주인이란 FK를 가진 오브젝트를 뜻한다.

 

웹 프로그램을 실행하면 다음과 같은 화면이 나올 것이다.

Mybatis와 같은 예전 방식이었다면 User, Board, Reply를 Join해서 Select해서 해당 페이지의 데이터를 다 들고왔을 것이다.

 

근데 ORM 방식을 사용하면 되게 간단하게 Board 테이블만 Select하면 된다.

Select * From Board where Id=1;

 

이렇게만 해주면 JPA가 Id가 1인 Board 모델이 필요하다는 것을 인식하고 Board가 들고있는 user 오브젝트 정보를 DB한테 User와 Board를 JOIN한 문장을 날린다. 이러면 DB는 그에 대한 정보를 JPA에게 다시 돌려준다. 

 

이러면 JPA는 Board 오브젝트가 있고, 그 내부에 User 오브젝트 정보도 들어가 있는 상태가 된다. 그래서 Board만 Select해도 User 정보가 같이 딸려오게 되는 것이다. 

 

게시글의 답변 정보인 Reply 정보도 필요하므로 다음 코드를  Board 클래스에 추가해준다.

private Reply reply;

 

그런데 하나의 게시글에는 한 명의 User만 존재할 수 있고, 여러 개의 Reply를 가질 수 있다. 그러면 Reply 정보를 DB에서 가져올 때 하나가 아닌 리스트로 가져와야 한다. 

@OneToMany
// @JoinColumn(name = "replyId")
private List<Reply> reply;

 

여기에선 JoinColumn 어노테이션이 필요가 없다. 만약 JoinColumn 어노테이션을 붙이면 Board 테이블이 다음과 같이 생성된다. 

 

Board 테이블

 

이를 방지하기 위해 mappedBy로 연관관계의 주인이 아니라는 것을 표시해주어야 한다. FK 키가 Board 클래스의 reply가 아니라 Reply 클래스의 board가 FK 즉, 연관관계의 주인이라는 뜻을 나타낸다. 

	@OneToMany(mappedBy = "board")
	private List<Reply> reply;

Reply 테이블

 

 

user 정보는 ManyToone 즉, 한 건 밖에 없으므로 EAGER 전략을 사용한다. 기본 전략으로 설정되어 있다.

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "userId")
private User user;

 

그런데 OneToMany의 경우 EAGER 전략을 사용하지 않는다. Board 테이블을 Select할 때 reply는 여러개가 될 수 있기 때문에 필요하면 가져오고 아니면 안가져오는 LAZY 전략을 사용한다. 이것 또한 기본 전략으로 설정되어 있다.

 

하지만 우리는 상세 페이지에서 댓글 창을 항상 보이게 할 것이기 때문에 EAGER 전략으로 바꿔줘야 한다. 댓글 펼치기 기능인 경우 LAZY 전략을 사용한다. 

@OneToMany(mappedBy = "board", fetch = FetchType.EAGER)
private List<Reply> reply;

 

 

 

출처 : https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9​