[QueryDSL] 5. 실무 활용 - 순수 JPA와 QueryDSL

 

 

1️⃣ 순수 JPA 리포지토리와 Querydsl 

 

- 순수 JPA리포지토리 

MemberJpaRepository

스프링 데이터 JPA 없이 순수한 JPA 만을 사용한 리포지토리이다. 

참고로 findById할 때 리턴타입을 Optional로 줬는데 이유는 id로 조회를 했을 때, 이에 해당하는 회원이 없을 수도 있기 때문에 Optional로 한번 감싸서 리턴해줬다. 

 

 

 

- 순수 JPA리포지토리 테스트

-> 앞에서 만든 MemberJpaRepository가 문제없이 잘 돌아가는지 단순히 확인하기 위한 테스트이다. 

(테스트 결과는 당연히 성공) 

 

 

2️⃣ Querydsl 사용 

 

- 순수 JPA리포지토리 : Querydsl 추가 

findAll()과 findByUsername()에 대해서 Querydsl짠 코드이다. 

(확실히 훨씬 가독성이 좋은 것 같다.)

 

 

- QueryDsl에 대한 테스트 추가 

앞에서 했던 테스트에서 findAll() 을 findAll_Querydsl()로, findByUsername()을 findByUsername_Querydsl()로 변환해서 테스트만 진행해주면 된다. (어차피 같은 기능을 하기 때문) 

 

 

⭐️ JpaQueryFactory 스프링 빈 등록해서 사용하는 방법 

지금 JpaQueryFactory를 사용할 때는 생성할 때는 

이런식으로 생성자에서 JpaQueryFactory를 새로 생성해서 EntityManagrer를 주입해서 사용하는 방식을 사용하고 있다.

 

그런데 그냥 JpaQueryFactory를 스프링 빈으로 등록해서 사용하는 방법도 있다. 

이렇게 빈으로 등록해주고, 그냥 의존성 주입받아서 사용해도 된다. 

이 방법으로 하면 롬복의 @RequiredArgsConstructor를 사용해서 생성자에 대한 코드를 줄일 수 있다는 장점은 있지만, 

테스트 할 때 의존성에 대해서 2개 추가해줘야 하기 때문에 테스트할 때는 조금 더 번거롭다는 단점이 있다. 

 

이건 그냥 선택해서 자기가 하고싶은 방식대로 하면 된다고 한다~~

 

 

❗️ 참고 : 동시성 문제에 대해서는 걱정하지 않아도 된다. 

왜냐하면 여기서 스프링이 주입해주는 엔티티 매니저는 실제 동작 시점에 진짜 엔티티 매니저를 찾아주는 프록시용 가짜 엔티티 매니저이다.  이 가짜 엔티티 매니저는 실제 사용 시점에 트랜잭션 단위로 실제 엔티티 매니저(영속성 컨텍스트)를 할당해준다. 

 

 

 

 

3️⃣ 동적 쿼리와 성능 최적화 조회 - Builder 사용 

 

MemberTeamDto 

: 조회 최적화용 DTO 추가 

 이번에는 생성자에 @QueryProjection을 사용해서 Q파일을 만들어주고 DTO를 프로젝션으로 조회해올 것이다. 

이때 QMEmberTeamDto를 생성하기 위해 ./gradlew compileJava 한번 해주고, build -> rebuild Project 해주기~

 

❗️ 참고 

@QueryProjection을 사용하면 해당 DTO가 QueryDsl에 의존하게 된다. 

이런 의존이 싫다면 해당 어노테이션을 제거해주고 Projection.bean(), Projection.fields(), Projections.constructor() 를 사용하면 된다.

https://hyejin.tistory.com/821

[QueryDSL] 4. 중급 문법

 

 

MemberSearchCondition

: 회원 검색 조건 

 

 

동적쿼리 : Builder 사용 

MemberJpaRepository

username과 teamname에 대해서 null 체크할 때는 StringUtils의 hasText() 함수를 통해 검증해줬다. 

따라서 null 이 아니면 BooleanBuilder 에 and 조건으로 추가해준다. 

 

동적쿼리를 완성한 builder 에 대해서는 where 조건에 builder를 추가해주기만 하면 된다. 

 

 

조회 예제 테스트

검색 조건에 35 ~ 40 살 사이를 조회하고, 그 다음 team 이름은 teamB인 회원을 검색하는 테스트이다. 

그렇게 해서 나온 테스트 결과는 member4가 잘 나오면 된다. 

 

 

 

4️⃣ 동적 쿼리와 성능 최적화 조회 - Where절 파라미터 사용 

 

MemberJpaRepository

: Where 절에 파라미터를 사용한 예제 

BooleanBuilder 사용할 때랑 비슷하긴 한데 이번에는 where 조건에 파라미터 로 조건을 나열했다. 

usernameEq, teamNameEq, ageGoe, ageLoe 메소드를 따로 빼서 조건으로 추가해줬다. 

이때 where 절에 Null은 무시되기 때문에 모두 추가해줘도 된다. 

 

이 방법의 장점은 조건 재사용이 가능하다는 점이다. 

 

-> 이런식으로 where 파라미터 방식은 다른 query에서도 재사용이 가능하다. 

 

 

 

5️⃣ 조회 API 컨트롤러 개발 

간단한 API를 만들기 전에 미리 샘플 데이터를 추가할 것이다. 

근데 이 샘플 데이터가 테스트에 영향을 주지 않도록 프로파일을 설정해준다. 

 

- 프로파일 설정 

src/main/resoureces/application.yml 

 

src/test/resources/application.yml

: 테스트는 기존 application.yml 을 복사해서 다음 경로로 복사하고, 프로파일을 test로 수정 

 

-> 이렇게 분리를 해주면 main 소스코드와 테스트 소스코드 실행 시 프로파일을 분리할 수 있다. 

 

 

- 샘플 데이터 추가

InitMember

InitMember 클래스안에 내부에 InitMemberService를 만들어서 Team과 Member 를 만들어준다. 

나중에 페이징 관련해서도 테스트해야하기 때문에 데이터를 100개 만들어둔다. 

 

그리고 이때 왜 굳이 InitMemberService 라는 것을 만들었는가? 에 대해서는 

@PostConstruct 어노테이션과 @Transactional 어노테이션이 함께 동작이 잘 안되기 때문이라고 한다. 

 

 

- 조회 컨트롤러

MemberController

여기서는 그냥 간단히 MemberSearchCondition만 파라미터로 전달해주면 된다. 

이 예제를 실행하기 위해서 포스트맨을 이용해서 테스트했다. 

 

http://localhost:8080/v1/members?teamName=teamB&ageGoe=30&ageLoe=60