[QueryDSL] 2. 예제 도메인 모델

https://www.inflearn.com/course/Querydsl-%EC%8B%A4%EC%A0%84/dashboard

실전! Querydsl - 인프런 | 강의

인프런 - 실전! QueryDSL 강의를 듣고, 공부한 내용을 정리했습니다. 😇

 

 

 

https://hyejin.tistory.com/740?category=1091560 

[스프링 데이터 JPA] 2. 예제 도메인 모델

섹션2에서 하는 예제 도메인 모델은 스프링 데이터 JPA와 동일하다고 한다. 

그래서 그냥 섹션2 정리는 넘어갈까 하다가 그냥 시간도 남고, 복습도 할 겸 정리한다. 

 

 

 

1️⃣ 예제 도메인 모델과 동작 확인 

간단한 도메인 모델이다. 

Member와 Team은 일대다 관계로 양방향 연관관계 매핑해주면 된다. 

 

 

Member 엔티티

@Setter

: 실무에서는 가급적 @Setter 어노테이션은 사용하지 않는 것이 좋다. (생성자로 해결하는게 좋음) 

 

@NoArgsConstructor(access = AccessLevel.PROTECTED)

: 기본 생성자는 public 으로 열어두면 여기저기서 사용하는 경우가 많을 것 같아서 막고 싶은데, JPA는 스펙상 기본 생성자를 PROTECTED까지는 열어둬야 해서 AccessLevel을 PROTECTED로 설정해줬다. 

 

@ToString()

: toString 를 사용할 때는 연관관계가 없는 필드만 설정해줘야 한다. 

왜냐하면 Team 을 포함해버리면 무한 루프로 Team에서 member를 호출하고, member가 team을 호출하고...

이러기 때문이다. 

 

@ManyToOne(fetch= FetchType.LAZY)

: XToOne 관계는 기본 전략이 EAGER라서 LAZY로 설정해 모든 연관관계는 지연 로딩 전략으로 해야 한다. 

 

changeTeam()

:  Member와 Team이 양방향 연관관계이기 때문에 Member의 Team을 설정해주고, 

반대로 Team의 Member List에도 Member를 세팅해줘야 한다. 

 

 

Team 엔티티

@OneToMany(mappedBy = "team")

Member와 Team은 지금 일대다 양방향 연관관계이다. 

이때 연관관계의 주인은 외래키가 있는 쪽이 되어야 하기 때문에  Member.Team이 연관관계의 주인이고, Team.members는 연관관계의 주인이 아니다. 

따라서 Member.Team이 데이터베이스 외래키 값을 변경하고, 반대편은 읽기만 가능하다.

 

 

데이터 확인 테스트

MemberTest

@SpringBootTest

: 테스트에서 스프링을 띄워서 테스트를 수행해야 하기 때문에 이 어노테이션을 추가해준다. 

 

@Transactional

: JPA의 모든 데이터 변경은 트랜잭션 안에서 동작해야 하기 때문에 트랜잭션을 걸어준다. 

이 어노테이션은 TEST에 있으면 테스트가 끝나고 알아서 롤백해줘서 DB에 테스트 데이터가 영향을 주지 않도록 한다.

 

 

MemberTest 테스트가 잘 되는 것을 확인할 수 있다. 

원래 테스트면 이렇게 Sysout으로 출력해서 하는게 아니라 자동으로 테스트를 하는게 좋은데 

이건 테스트 예제가 간단하고 학습하는거니까 이렇게 하고 넘어간다고 한다~..