Entity → DTO - showMeTheMoneyPrac/BE_Repo GitHub Wiki

1️⃣ 프로젝트에서의 DB에서 반환되는 형태를 Entity class에서 DTO의 형태로 바꾼 이유

하나의 서비스에 대해서 각 Entity별 모든 정보가 필요한 것이 아닌 ResponseDTO로 사용자(프론트)가 각각의 테이블에서 필요한 정보만을 JOIN을 통해 DB에서 추출하는 방식이 이전의 Spring-data-JPA를 활용하는 방법보다 효율적일 것이라고 판단하여 이번 프로젝트에 도입하였다.

물론 Spring-data-JPA의 1차 영속성 캐싱이 존재하지만 하나의 트랜잭션에서 동일한 엔터티를 여러 번 호출하는 일이 없기에 효율적이지 못하다고 생각한다.

그렇기에 Spring-data-JPA형태로 각 Entity Class를 전체 추출하여 각 ResponseDTO의 형태에 맞게 builder 패턴을 활용할 필요도 없고 List형태의 경우, for문을 한 번 더 실행할 필요도 없어진다. 이에 대한 부하테스트 결과 데이터의 반환 속도와 에러율에서 훨씬 좋은 결과를 나타내었다.

인텔리제이 디버그 쿼리 결과

스크린샷 2022-06-08 오후 9 26 26
스크린샷 2022-06-08 오후 3 54 28



부하테스트 결과표(TPS 증가율 530%)

스크린샷 2022-06-01 오후 3 02 32

2️⃣ DTO 반환 활용방안

기존의 Spring-data-JPA를 활용하여 Entity 객체를 모두 호출하는 방식에서 QueryDsl를 활용하여 각 테이블간의 연관관계를 판단, Inner Join을 활용하여 각 테이블에서 필요한 데이터만을 추출하였다.

→ Querydsl 사용 이유 JPQL도 존재하였으나

  1. 문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다.
  2. 자동 완성 등 IDE의 도움을 받을 수 있다.
  3. 동적인 쿼리 작성이 편리하다.
  4. 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있다.

위의 이유로 Querydsl을 사용하였다.

3️⃣ 기술에 대한 참고 문헌

QueryDsl 활용 원리

QueryDsl 활용 방법

[[Querydsl] 튜플이나 DTO로 결과 반환하기](https://doing7.tistory.com/129)

QueryDsl 장점

[Spring Boot에 QueryDSL을 사용해보자](https://tecoble.techcourse.co.kr/post/2021-08-08-basic-querydsl/)

4️⃣ 기술의 장점

Spring-data-jpa를 활용하여 Entity를 호출하여 For문을 다시 한 번 사용하여 ResponseDto 형태에 맞게 진행하던 로직을 for문을 사용하지 않고 직접적으로 ResponseDto에 알맞은 형태로 반환이 가능하다. → 이에 따라 데이터를 반환하는 속도가 놀라울 정도로 개선되었다.

5️⃣ 기술의 단점

ResponseDto에 해당하는 각 변수의 이름이 Entity의 이름과 동일해야 인식할 수 있으며, 그렇지 않을 경우 alias를 활용하여 각 ResponseDto의 변수명과 일치하게 설정하여야 사용이 가능하다.

6️⃣ 추가적 방안은?

Redis를 활용한 캐싱을 도입하였을 때, 캐싱 오염이 존재하지 않는다면 더욱 효과적인 데이터 반환 속도를 나타낼 수 있을 것이라고 판단된다.

⚠️ **GitHub.com Fallback** ⚠️