CS 잡지식 썸네일형 리스트형 컬렉션(Collection) fetch join 시, 발생하는 [데이터 중복] 문제!(소위 [데이터 뻥튀기]라고도 부름) [1:다]에서 생기는 문제이기도 함. (아래 사이트 참조) (하이버네이터 6부터는 자동으로 데이터 중복 해결해줌. (Feat. distinct) https://jbluke.tistory.com/346 1：多 jbluke.tistory.com @Entity @Table(name = "ORDERS") @Getter @Setter @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Order { @Id@GeneratedValue @Column(name = "order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name="member_id") private Member .. 더보기 DTO는 그 어떠한 [도메인 엔티티]를 의존해서는 안된다 package jpabook.jpashop.controller; import jpabook.jpashop.domain.Address; import jpabook.jpashop.domain.Order; import jpabook.jpashop.domain.OrderItem; import jpabook.jpashop.domain.OrderStatus; import jpabook.jpashop.repository.OrderRepository; import jpabook.jpashop.repository.OrderSearch; import lombok.Data; import lombok.RequiredArgsConstructor; import org.springframework.stereotype.Reposit.. 더보기 컬렉션(Collection) 조회 시 생기는 [데이터 중복] 문제(미완성) https://jbluke.tistory.com/346 1：多 jbluke.tistory.com 위 내용에서 [데이터 뻥튀기] 문제가 무엇인지 파악하자. [1 : 多] 관계(@~~ToMany)에서 多는 컬렉션(Collection)으로 엔티티가 표현이 된다. 위 사이트에도 나와 있듯이, 1 : 多에서는 항상 [데이터 중복] 문제가 발생을 한다. 고로, [도메인 엔티티] 구현 시, @~ToMany로 인해 컬렉션(Collection)을 사용할 때에는 반드시 이 [데이터 중복] 문제를 최적화해야 한다. 그 방법에 대해서는 스프링 부트 JPA 활용2 ppt 21페이지를 참조하면 된다. /*** 컬렉션에 대한 fetch join 시 주의 사항!!! ***/ 더보기 이상적인 아킥텍쳐 설계 구조에 대한 설명서 Template 더보기 API 개발 시, [JPQL의 작성 방식]의 선택 기준(Feat.Fetch Join,new 연산자를 이용한 DTO 직접 변환) 쿼리 방식 선택 권장 순서 1. 우선 엔티티를 DTO로 변환하는 방법을 선택한다 : 절대적 지침 2. 필요하면 페치 조인으로 성능을 최적화 한다. [대부분의] 성능 이슈가 해결된다. 3. 그래도 안되면 DTO로 [직접] 조회하는 방법을 사용한다 : Repository 계층에서 new 연산자로 JPQL 작성. (3에는 단점이 있고, 그에 따른 해결 방법도 있다. 아래 사이트를 참조) https://jbluke.tistory.com/421 https://jbluke.tistory.com/manage/newpost/421 jbluke.tistory.com (https://jbluke.tistory.com/419의 V4 메서드 참조) DB 최적화 기법 - Projection 대상을 필요한 것만으로 한정(Feat.. 더보기 특정 API 스펙에 맞는 JPQL문을 작성해야 할때!! https://jbluke.tistory.com/419 DB 최적화 기법 - Projection 대상을 필요한 것만으로 한정(Feat.DTO) @GetMapping("/api/v3/simple-orders") public List orderV3() { //fetch join을 사용하여 Order 조회! List findOrders = orderRepository.findAllWithMemberDelivery(); // 미리 정해진 API 결과 스펙을 반환하기 위하여, DTO에 정해진 스펙 jbluke.tistory.com (위 사이트의 맥락에 이어서 설명을 하겠다) 보통, JPQL은 Repository 계층에서 작성이 된다. 근데, Repository는 거의 절대적으로 [조회]를 할 때 [객체]를 조회하.. 더보기 DTO에는 2종류가 있다(Feat. RequestDTO, ResponseDTO) API 개발 시에는 항상 DTO를 2개로 만들어서 개발을 하자!!!! RequestDTO : [클라이언트]에서 API를 호출할 때 필요한 스펙 ResponseDTO : [서버]에서 반환하는 [API 결과 스펙] EX) 시나리오 : 이름(name)과 나이(age)를 입력해서 API를 호출하면, 서버에서 그 사람의 소속 대학(university)를 반환하 는 API가 있다고 하자. 1] 클라이언트가 API 호출 시, 필요한 API 스펙 { "name" : "jin young" "age" : "20" } 2] 서버의 API 결과 스펙 { "university" : "DONG-A" } -> 1]에서 클라이언트가 이름(name)과 나이(age)를 보내면, 서버에서 그 정보를 객체(DTO)로 받아야 한다. (Spr.. 더보기 DB 최적화 기법 - Projection 대상을 필요한 것만으로 한정(Feat.DTO) @GetMapping("/api/v3/simple-orders") public List orderV3() { //fetch join을 사용하여 Order 조회! List findOrders = orderRepository.findAllWithMemberDelivery(); // 미리 정해진 API 결과 스펙을 반환하기 위하여, DTO에 정해진 스펙대로 필드값들을 넣어 준다. List resultList = findOrders.stream() .map(o -> new SimpleOrderDTO(o)) .collect(Collectors.toList()); return resultList; } 위 API에 대한 쿼리문은 아래와 같다. @GetMapping("/api/v4/simple-orders") publ.. 더보기 이전 1 ··· 7 8 9 10 11 12 13 ··· 16 다음
