TIL_210525

1. Facts(사실, 객관)

- 값 타입 컬렉션 공부

- 값 타입 address 실습

- 메서드에서 Dto 변환하여 조회하기(LAZY) 공부

2. Feelings(느낌, 주관)

- 점점 더 JPA에 대한 관심을 늘려나가고 있습니다. 어떻게하면 JPA를 올바르게 생성, 조회, 수정할 수 있는지 배워나가는 중입니다. 이전에 혼자서 토이 프로젝트를 낑낑되면서 연관관계를 힘들어 했는데, 많은 부분 궁금증이 해소되었습니다. 값 타입이라는 단어가 확 와닿지는 않지만 계속 반복하니, 연관관계와 더불어 중요한 부분이라는 것을 깨달았습니다. 역시나 직접 값타입 Address를 만들어보면서 실습하니 이해가 잘 되었습니다.

3. Findings (배운 점)

- 엔티티를 그냥 반환하면 스펙이 바뀔 수 있으므로 꼭 dto를 이용한다

 

- @Embbeded 타입으로 Address를 선언하고 JPQL로 생성하여도, DB에서는 Address 테이블이 아니라, 해당 클래스가 가지고 있는 변수들이 자신이 속한 엔티티에 포함된다.

 

- 임베디드 타입은 값타입 이므로 일반 변수와 같이 취급되어, 연관관계와는 달리 독립적인 클래스가 생성되지 않는다. 따라서 부모 엔티티의 생명주기에 맞춰진다.

 

- LAZY 전략으로 조회한다는 것은 프록시 전략을 사용한다는 것이다. 프록시는 무조건 초기화 작업이 필요하다. 따라서, 연관관계를 조회하고 싶을 떄는 무조건 초기화 해야한다.

List<Order> orderList = orderRepository.findAll();
for(Order order : orderList) {
    order.getMember().getName();
    order.getDelivery().getAddress();
}

 이렇게 강제로 연관관계의 아무 필드를 호출해야 비로소 Order의 연관관계인 Member와 Delivery도 조회할 수 있다. 

(EAGER를 사용하면 더 복잡한 결과만 나올뿐이니 절대 사용을 금지한다.)

(Best는 LAZY + FETCH 전략을 쓰는 것이며 추후에 배운다.)

 

-  @Embbeded Address는 ResponseDto를 생성할 때, 필드를 적지 않고 private Address adress를 적어도, 알아서 해당 필드를 조회한다. (RequestDto에서는 단순 address 사용이 예외를 발생시켰는데, 추후 자세한 확인이 필요하다.)

 

- 값타입 컬렉션은, 각각 테이블이 생성된다. 또한 모든 칼럼을 pk로 지정한다. 하지만 독립적인 id는 가지지 못하고 보통 자신의 주인 엔티티의 id를 외래키로 가지고 있다. 기본적으로 casecade 전략과 orphanRemoval=true 를 포함해야 한다. 왜냐하면 값타입이기 때문에 생명주기를 가지지 못하기 때문이다. 따라서 자신이 속한 엔티티의 생명주기에 맞춰진다.

 

*값타입 컬렉션 다루기

생성 : 생성자를 통해(혹은, add를 통해) 주인 엔티티에 set을 한다면, 주인 엔티티가 생성될 때 같이 생성된다.

조회 : LAZY 전략을 사용하므로 강제 초기화를 시켜야 한다.

수정 : 수정하기 위해서, remove를 하고 새로운 값을 add 하면, 단순히 1개 삭제, 1개 추가가 아니다. 1개를 삭제하는 순간 전체 컬렉션값을 초기화하고 다시 모두 추가한다. 이것 때문에, 값타입 컬렉션을 사용하지 않고 1:N으로 매핑하기도 한다. 이 때 기본적으로 casecade 전략과 orphanRemoval=true 를 포함해야 한다.

 

- 값타입은 공유하지 않도록 조심해야 한다. 객체참조가 가능하기 때문에, 언제 값이 바뀔지 모른다. 값이 바뀌는 것은 문제가 아니지만, 같은 객체를 참조하는데 값이 바뀌면 원치 않은 수정이 발생한다.

 

4. Affirmation (자기 선언)

- 나는, 어려운 내용일지라도 여러번 반복해서 이해하기 위해 노력하는 사람이다