부트캠프 51일차 후기

드디어 며칠 간 괴롭혔던 문제를 해결했다, 이전에는 기울기와 y절편을 직접 구했는데, 문제를 쭉 내리니까, 마지막에 선분끼리의 교점을 구하는 식이 나와있었다. 적용하니까, 바로 맞았다. 너무나 허망하다고밖에 말할 길이 없다...여기에 추가적으로 문제를 하나 더 풀었는데, 인덱스를 활용해서 풀려하니 머릿속이 복잡해졌지만, Stack을 활용하니 쉽게 풀수 있었다.

 

오늘은 이어서 JPA의 심화에 대해 공부를 하였다. 가장 기억에 남는 것은 Projection에 대한 것이다. 단순하게 JPARepository를 사용할 때, 반환 값을 DTO를 설정해주면, 간단하게 해당 DTO로 Projection이 가능하다. 만약 DTO가 여러개라면, 제너릭을 활용해서 DTO 클래스를 사용할 때, 지정해 줄 수 있다는 것 또한 배웠다.

@Repository
interface MemberRepository : JpaRepository<Member, Long> {
		fun <T> findByEmail(email: String, type: Class<T>): T?
} // type에 DTO 타입을 넣어준다.

JPQL에서 사용을 할 수 있는데, alias를 재작성을 하거나, DTO 클래스를 지정하지만, 패키지 경로까지 작성을 해야하는 번거로움이 존재한다. 그래서 보통 JPQL을 통한 Projection이 아닌 QueryDSL을 활용한 Projection이 더 권고된다고 한다.

 

강의에서 제시한 QueryDSL에서의 Projection 방법은 4가지이다.

첫번째는 Projections.bean을 사용하는 것인데, select에 Projection.bean을 넣고, 원하는 Projection을 지정하는 것이다. 이 문 방법은 일반적으로 권장되지 않는데, DTO가 Nullable하고 Mutable한 값이야하기 때문이다.

두번째 방법인 Projections.fields도 마찬가지로 동일한 문제를 안고 있기에 권장되지 않는다.

세번째 방법은 Projections.constructor를 사용하는 것이다. Projections.bean과 비슷하게 사용하지만 bean이나 fields의 문제점을 가지지 않아서 유용하게 사용할 수 있다. 다만, 단점은 생성자의 순서를 완벽하게 지켜야한다.

마지막 네 번째 방법은 DTO 생성자에 @QueryProjection을 붙이는 방법이다. 붙인 다음, compileKotlin을 실행하면 QueryDSL에서 해당 DTO를 QClass로 생성해준다. 그리고 select 문에 해당 QClass를 사용하면 순서를 지킬 필요가 없어진다. 단점은 DTO는 QueryDSL과 무관한 객체인다. QueryDSL에 의존하게 된다는 점이다.

 

override fun findByEmail(email: String): SimpleMember? {
    return jpaQueryFactory
        .select(
            QSimpleMember(
                member.id,
                member.email,
                member.nickname
            )
        ).from(member)
        .where(member.email.eq(email))
        .fetchOne()
}

결국엔 Projections.bean이랑, @QueryProjection을 적당히 비교해가며 사용하는 것이 좋을 것 같다.

 

내일은 강의를 다 듣도록하자.