17. 양방향 연관관계와 연관관계의 주인 2 - 주의점, 정리

⚡ 생각대로 살지 않으면 사는대로 생각한다.

⚡ 나는 어차피 잘 될 놈이다. 이미 잘 되고 있고, 계속해서 잘 되고 있다.

양방향 매핑시 가장 많이 하는 실수

연관관계 주인에 값을 입력하지 않음

위와 같은 코드처럼 Team에 Member를 추가했다.
그런데...;;

MEMBER 테이블의 결과를 보면, MEMBER_ID, USERNAME은 잘 나오는데, TEAM_ID 가 null값이다.
왜 그럴까...? 🧐

연관관계의 주인은 원래 MEMBER 클래스의 team이 연관관계의 주인이다.

@Entity
class Member {
	@ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;

mappedBy로 지정한 Team의 members는 읽기 전용이기 때문에, add를 해도 값이 들어가지 않는다.

그래서 이를 인지하고 다시 코드를 작성하면...

TEAM_ID가 제대로 나온다..!!

양방향 매핑시 연관관계의 주인에 값을 입력해야한다.

사실.. 순수한 객체 관계를 고려하면 항상 양쪽 다 값을 입력해야 한다.

여기서 List에 따로 Member를 넣어주지 않았음에도 불구하고, for문으로 순회해보면,

이런 결과가 나온다.

find 했을 때, 아래 쿼리가 날라가고,

List로 순회할 때 아래 쿼리를 날린다.

JPA가 Team에서 members를 실제 사용하는 시점에 쿼리를 한번 날린다. 그래서 add()메서드로 컬렉션에 값을 넣어주지않더라도, JPA를 통해서 값이 출력이 된다.

지금 이렇게 SELECT가 나오는 것은 아래 코드와 같이 em.flush(),em.clear()가 있기 때문이다.

그런데, 저 두 문장을 주석처리하면, 어떻게 될까...?

일단 em.persist()메서드로 영속성 컨텍스트에는 들어가게되겠지만, DB에 들어가진 않을 것이다. 왜냐하면 tx.commit()시점에 쿼리를 날리게되니, INSERT 쿼리만 두번 날릴 것이다.

그리고 밑줄 친 team.getMembers().add(member); 부분을보면, 주석처리하지 않았을 땐, 향상된 for문을 돌며, member를 출력하지만, 주석처리를 하게 되면, 향상된 for문으로 인해서 출력되는 값은 없다. 아래 사진처럼..

결과

결론은 객체지향적인 코드작성을 위해서 항상 양쪽에 값을 설정해주는 것이 좋다!!

양방향 연관관계 주의

• 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자

• 연관관계 편의 메소드를 생성하자

  • 

    이렇게 양방향으로 넣어주는 코드를 작성하긴하는데, 사람인지라 까먹을 때가 있다.
    그래서 차라리 한쪽에서 값을 세팅하면, 다른 쪽도 같이 되도록 편의 메서드를 만들자는 의미이다.

  • 예를 들면,

    public void setTeam(Team team) {
         this.team = team;
         team.getMembers().add(this);
     }

    이런식으로..
    연관관계 편의 메서드는 한쪽에서만 작성해놓으면 된다.

    연관관계 편의메서드를 좀 더 깊이있게 사용하려면, 복잡하다. 궁금하다면 책을 참고하면 된다. 실무에선 여기까지만 해도 된다.

• 양방향 매핑시에 무한루프를 조심하자

  • toString()을 하면, 참조에 참조에 참조를 계속하게되어 StackOverFlow를 마주하게 된다.
    • Lombok으로든 아니든 toString()은 사용하지 않도록 해야한다.
  • JSON 생성 라이브러리를 사용할 때, Controller에서 Entity를 반환하지 않도록 해야한다.
    • Entity를 반환하면 두가지 문제가 생긴다.
      • 무한루프
      • Entity를 API에 반환하면, Entity를 변경하는 순간 API의 스펙이 바낀다.
        • 이 때는 DTO로 변환해서 반환하도록 해야한다.

양방향 매핑 정리

• 단방향 매핑만으로 이미 사실 연관관계 매핑은 완료된 것
  • JPA 모델링 설계시엔, 단방향으로 설계가 끝나도록 해야한다.
• 양방향 매핑은 반대방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
  • 객체지향에서 사실 양방향으로 설계해서 좋을 건 없다. 오히려 고민거리만 많아진다.
  • 설계는 단방향 매핑으로만 해도 이미 끝난 것이다.
• JPQL에서 역방향으로 탐색할 일이 많음

• 단방향 매핑만 잘 해두면 양방향은 필요할 때 추가하면 된다.

  • 테이블에 영향을 주지 않음

연관관계의 주인을 정하는 기준

• 비즈니스 로직을 기준으로 연관관계의 주인을 선택하면 안 됨

• 연관관계의 주인은 외래키의 위치를 기준으로 정해야함

와우... 너무 좋다...
사랑해요 김영한...♥️

-끝-