둘셋 개발!

컬렉션인 일대다 관계를 조회하고, 최적화 하는 방법이다. 일대다 관계이기 때문에 데이터가 배로 커지기 때문에 문제가 발생하고, 또한 중복도 발생한다 1. 엔티티 조회방식 SQL에 distinct를 추가해서 같은 엔티티가 조회되면, 애플리케이션에서 중복을 걸러준다. 하지만 이에 치명적인 단점은 페이징이 불가능하다는 것이다. 애플리케이션에서는 Order의 id가 같으면 중복을 제거 해주지만, 데이터베이스에서는 한 줄에 있는 모든 데이터가 같아야 중복이 되기 때문에 데이터가 배가 되는 문제는 피할 수가 없다. 따라서 원하는대로 페이징을 할 수 없다. 해결방법은 hibernate.default_batch_fetch_size, @BathSize를 적용하는 것이다. 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한..

주문 객체는 회원과 배송정보가 함께 있기 때문에 이때 발생하는 이슈들을 잘 다뤄봐야 한다. order객체 mem와 address는 지연로딩으로 설정되어 있기 때문에 order를 불러올 때 이 둘은 프록시 객체가 있다. 그래서 json은 이를 프록시 객체를 어떻게 생성하지 모르기 때문에 Hibernate5Module을 스프링 빈으로 등록시킴. 이렇게 되면 지연로딩은 null로 처리되고 정상적으로 돌아간다. 하지만 엔티티를 외부에 그대로 노출시키는 것은 좋지 않다. 그래서 해결방법은 DTO를 생성하는 것이다. 하지만 이때 성능문제가 발생한다. order.getMember().getName() 과 order.getDelivery().getAddress() 를 할 때 지연로딩이 초기화 된다. 그러면 name과 ..

이렇게 하면 다음과 같은 문제점이 발생한다. 문제점 엔티티에 프레젠테이션 계층을 위한 로직이 추가된다 -> 같은 엔티티에 대해 api가 용도에 따라 다양하게 만들어 지는데, 한 엔티티에 모든 요청 요구사항을 담기 힘들다 엔티티가 변경되면 api스펙이 변한다 (회원 조회) 컬렉션을 직접 반환하면 나중에 api 스펙을 변경하기 어렵다 결론 api 요청, 응답 스펙에 맞춰 별도의 DTO를 만든다 DTO란 ? Data Transfer Object의 약자로, 계층간 데이터 교환을 위한 자바빈즈를 뜻한다. (출처 : 이리의 개발 이야기 https://iri-kang.tistory.com/5) 엔티티를 API 프렉에 노출 하면 안된다 (회원 조회) 제네릭 클래스로 감싸줘서 나중에 필요한 필드를 추가할 수 있다. (참..