전체 글 (35) 썸네일형 리스트형 프록시의 PK만 조회하면, 1+N 쿼리 문제가 터지지 않는다? https://praaay.tistory.com/6 xToOne 관계 조회 API 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화하는 방법을 단계별로 정리하려 합니다. 주문과 배송정보 그리고 회원을 조회하는 API를 만들praaay.tistory.com 위 글에도 정리했지만, 조회 API에서 엔티티가 지연 로딩으로 설정되었다면 1+N 쿼리가 나가는 문제를 조심해야 합니다.특히 아래 코드와 같이 엔티티를 DTO로 변환하는 과정에서 프록시 객체에 접근하는 경우라면 프록시 객체가 초기화되면서 1+N 쿼리가 나가는 문제가 발생합니다. 하지만 1+N 쿼리가 나갈 것이라 예상했던 상황에서 1+N 쿼리가 나가지 않았던 경험을 이야기해보려 합.. CASCADE (영속성 전이) CASCADEcascade는 영속성 전이 속성으로 특정 엔티티를 영속 상태(persist)로 만들 때 연관된 엔티티도 함께 영속 상태(persist)로 만들 때 사용합니다. cascase는 즉시 로딩이나 지연 로딩과는 관련 없습니다. Child child1 = new Child();Child child2 = new Child();Parent parent = new Parent();parent.addChild(child1);parent.addChild(child2);em.persist(parent);em.persist(child1);em.persist(child2); Parent 엔티티와 Child 엔티티가 다대일 연관관계를 형성할 때 위 코드와 같이 parent에 child를 넣더라도 persist는 따.. 즉시 로딩과 지연 로딩 https://praaay.tistory.com/27 프록시 (Proxy)프록시는 엔티티 객체를 흉내 낸 가짜 객체입니다. 프록시 덕분에 실제 엔티티를 조회하는 시점을 미룰 수 있습니다.그렇다면, 실제 엔티티를 조회하는 시점을 미뤄야 할 상황은 언제일까요? Mepraaay.tistory.com프록시를 정리한 글의 연장선으로 즉시 로딩과 지연 로딩에 대해 이야기해 보겠습니다. 위 그림처럼 Member 엔티티와 Team 엔티티가 연관관계로 묶여있을 때, Member 엔티티를 조회하면 연관관계로 묶인 Team 엔티티까지 조회해야 할까요? 두 엔티티를 모두 필요로 하는 상황이라면 좋겠지만, 위 그림처럼 Member 엔티티만 필요로 한다면 연관관계로 묶였다고 하더라도 두 엔티티를 함께 조회할 필요는 없습니다. M.. 프록시 (Proxy) 프록시는 엔티티 객체를 흉내 낸 가짜 객체입니다. 프록시 덕분에 실제 엔티티를 조회하는 시점을 미룰 수 있습니다.그렇다면, 실제 엔티티를 조회하는 시점을 미뤄야 할 상황은 언제일까요? Member와 Team 엔티티를 예로 들어보겠습니다. Member와 Team 엔티티는 일대다 단방향 연관관계로 연결되어 있습니다. 이때 Member 엔티티를 조회하면 Team 엔티티도 당연히 조회되어야 할까요? 그렇지 않습니다. 회원과 팀 엔티티를 함께 필요로 하는 경우라면 두 엔티티를 한 번에 가져오는 게 좋겠지만, Member 엔티티를 조회할 때 항상 Team 엔티티가 조회된다면 회원 엔티티만 필요할 경우에는 불필요한 쿼리가 나가며 성능 측면에서 불리하게 작용합니다. 따라서 우리는 연관관계가 걸려있는 엔티티끼라도 하나.. 1장 오브젝트와 의존관계(4). 의존관계 주입(DI) 1장. 오브젝트와 의존관계초난감 DAODAO의 분리DAO의 확장제어의 역전(IoC)스프링의 IoC싱글톤 레지스트리와 오브젝트 스코프의존관계 주입(DI)정리오브젝트와 의존관계(3)에 이어서 IoC와 단짝인 의존관계 주입(DI)에 대해 살펴봅시다. 의존관계 주입(DI)앞선 글에서 스프링 IoC 기능을 굉장히 강조했습니다.지금부터 알아볼 의존관계 주입은 스프링 IoC 기능의 대표적인 동작원리입니다. 사실 지금까지 외부에서 오브젝트를 생성하여 생성자로 오브젝트를 주입했는데 이 과정도 의존관계 주입이라 볼 수 있습니다. 먼저 의존관계에 대해 이야기해 봅시다. 의존관계란 A 클래스의 인스턴스 변수로 다른 B 클래스 타입을 가지는 것을 말합니다. 이때 A 클래스가 B 클래스에 의존한다고 볼 수 있습니다. 그리고 두 .. 1장 오브젝트와 의존관계(3) 스프링의 IoC, 싱글톤 레지스트리와 오브젝트 스코프 1장. 오브젝트와 의존관계초난감 DAODAO의 분리DAO의 확장제어의 역전(IoC)스프링의 IoC싱글톤 레지스트리와 오브젝트 스코프의존관계 주입(DI)정리오브젝트와 의존관계(2)에 이어서 스프링의 IoC와 싱글톤 레지스트리와 오브젝트 스코프에 대해 살펴봅시다. 스프링의 IoC이전 글에서는 초난감 DAO를 개선하고 객체지향 프로그램을 지향하는 방향을 살펴봤다면 이번에는 스프링을 살펴볼 차례입니다. 스프링은 매우 많은 기능을 제공하지만, 핵심은 바로 빈 팩토리 또는 애플리케이션 컨텍스트라고 불리는 것입니다. 애플리케이션 컨텍스트는 앞서 구현했던 DaoFactory를 일반화한 것입니다. DaoFactory가 설계도의 역할로 오브젝트 생성과 관계 주입의 책임을 가졌던 것처럼 애플리케이션 컨텍스트도 스프링 환경에.. 1장 오브젝트와 의존관계(2) DAO의 확장, 제어의 역전(IoC) 1장. 오브젝트와 의존관계초난감 DAODAO의 분리DAO의 확장제어의 역전(IoC)스프링의 IoC싱글톤 레지스트리와 오브젝트 스코프의존관계 주입(DI)정리오브젝트와 의존관계(1)에 이어서 DAO의 확장과 제어의 역전(IoC)에 대해 이야기 나눠봅시다.DAO의 확장오브젝트와 의존관계(1)에서 초난감 DAO를 팩토리 메서드 패턴과 템플릿 메소드 패턴으로 상속을 사용하여 DB 커넥션을 가져오는 코드를 클래스 계층으로 분리했습니다. 하지만 상속을 사용한다는 것이 단점으로 작용했습니다. 지금까지는 DB 커넥션을 가져오는 관심사를 분리할 때 독립된 메소드로 분리하고, 다음에는 상하위 클래스로 분리했습니다. 이번에는 DB 커넥션을 가져오는 관심사를 아예 독립적인 클래스로 만들어 보겠습니다. 이제 UserDao에서는.. 1장 오브젝트와 의존관계(1) 초난감 DAO, DAO의 분리 1장. 오브젝트와 의존관계초난감 DAODAO의 분리DAO의 확장제어의 역전(IoC)스프링의 IoC싱글톤 레지스트리와 오브젝트 스코프의존관계 주입(DI)정리 초난감 DAO1장 오브젝트와 의존관계에서는 스프링이 어떤 것이고, 무엇을 제공하는지보다는 스프링이 관심을 갖는 대상인 오브젝트의 설계와 구현, 동작원리를 살펴보겠습니다. 오브젝트에 대한 관심은 결국 객체지향 설계로 이어지게 됩니다. 객체지향 프로그래밍이 제공하는 해택을 누릴 수 있도록 만드는 것이 스프링의 핵심 철학입니다. 사용자 정보를 저장하고 조회하는 DAO(Data Access Object)를 구현하고 코드를 리팩터링 하는 과정 속에서 관심사 분리, 클래스 분리, 인터페이스 도입, 관계 설정 책임의 분리 등 다양한 개선점들을 살펴봅시다. 사용자 .. 이전 1 2 3 4 5 다음
