[스프링 부트와 JPA 활용] 2편

[핵심 내용]

• Entity를 외부에 노출 하지 말 것  (DTO 사용할 것) ⭐⭐⭐⭐⭐
• 의존관계는 반드시 한방향으로 흐르게 만들 것 ( order -> service -> repository ) ⭐⭐⭐⭐
• Command 와 Quary를 분리 
• Transaction이 연결되어 있으면, 영속성 컨텍스트에서 조회, 수정 ~ 
• DTO 생성 이유는 Entity와 관계를 끊어주기 위함 ( One To Many 주의 )

 

회원 등록/ 수정/ 조회 API

• API 개발에서는 핸들러 메서드 생성시 필요에 맞게 DTO 생성해서 사용 
  • 리턴값, 입력값의 클래스(DTO)를 새로 생성해서 사용 
  • 필요한 필드값만 사용할 수 있고, 응답값의 key값도 변경 가능
• 조회시 응답 객체를 조회할 멤버 List를 한번 감싸서 다른 필드값을 넣어줄 수 있다. ( 유연성 👍 ) 그렇지 않으면 json형태로 바로 출력됨. 추가 수정시 (유연성이 낮아짐 )

 

지연 로딩

• 엔티티를 직접 노출할 떄에는 양방향 연관관계가 걸렸을 때는 한 곳에 @JsonIgnore 처리 (무한루프 방지)
• 지연로딩을 피하기 위해 (fetch = LAZY -> EAGER ) 변경하지 말것!!  ⭐⭐⭐

 

성능 최적화 ( ? To One )⭐⭐⭐⭐⭐

• DTO 클래스를 생성하고, 필요한 필드값만 포함한 생성자를 만들어서 사용된다. 
• join fetch를 사용해서 JPQL로 보내면 쿼리 한번으로 원하는 정보를 다 가져올 수 있다. (LAZY 무시)
• JPA -> DTO 변환 ( 최적화가 필요할 떄 사용 ) 
  • Entity와 DTO의 관계도 끊고 JPA를 이용해서 변환한다. ( 재활용이 어렵지만, 최적화는 👍 ) 

 

성능 최적화 ( One To Many )⭐⭐⭐⭐⭐

• DTO 생성 이유는 Entity와 관계를 끊어주기 위함 ( One To Many 주의 )
  • DTO 사용시 쿼리가 너무 많아진다. 그러므로 join fetch 사용하면 쿼리 한번으로 가능
• Entity 외부 노출 주의
• JPA에서 SQL에 distinct를 추가해서 중복을 막아준다. 
• 단점! ( 페이징이 불가능 )
• 컬렉션 패치 조인은 1개밖에 사용할 수 없다.