• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

Jpql질문

20.10.08 20:47 작성 조회수 307

15

Jpql, querydsl 을 사용하면 좋다고 하셨는데

운영시에나 개발시에나 모든 상황에

결국 데이터가 안맞는 것은 대부분이 쿼리가 잘못돼서 그렇더라구요

이때 마이바티스 같이 네이티브 쿼리로 작성된 쿼리를 보고 뭐가 문제인지 판단해야 하는데

오히려 네이티브 쿼리 보는게 jpql, querydsl 보는 것 보다 쉽지 않나요?

-----

조금이라도 복잡한 쿼리라면 결국 네이티브 sql을 직접 작성하면서 데이터를 맞춰가면서개발하게 되는데 jpa를 사용하면 네이티브 쿼리로 테스트 하면서 작성된 쿼리를 다시 jpql이나 querydsl로 바꾸는 과정이 필요할 것 같아서 불편해 보이는데 어떤가요?

---

즉 jpa보다 마니바티스가 좋다고 생각되는 부분은

1.마이바티스를 사용하면 쿼리를 보자마 판단하기 쉽다. 쿼리를 돌려보려면 결국 애플이케이션을 실행해야 jpql이나 querydsl의 쿼리결과를 볼 수가 있다는거죠 

2. 테스트하며 쿼리 작성 후 jpql 맟 querydsl로 변환이 필요없고 바로 파라미터 문법만 바꿔서 복붙하면 된다

Jpa가 객체지향을 위한 건 알지만 실무에서

저런 단점들이 유지보수에 엄청 안좋을 것 같은데 어떻게 생각하시는지 궁금합니다

Jpql을 보니 문득 의문이 들었어요

감사합니다!

답변 3

·

답변을 작성해보세요.

15

안녕하세요. lbd4946님 좋은 질문입니다.

저도 SQL를 좋아하고 또 익숙한 개발자여서, 공감되는 부분이 많네요.

먼저 왜 JPA를 사용하게 되는지를 고민해보아야 합니다. 결국 패러다임의 전환인 것이지요.

기존에 테이블 중심에서 객체 중심으로의 큰 전환이 일어납니다.

SQL과 데이터 중심에서, 엔티티 객체와 자바 코드를 중심으로 변화가 일어납니다.

기존에는 SQL을 항상 먼저 실행하고, 그 다음에 그 SQL을 애플리케이션 코드에 복사해서 사용합니다.

그런데 JPA를 사용하게 되면 대부분의 경우 SQL이 먼저가 아니라 엔티티 객체와 자바 코드를 먼저 작성하게 됩니다.

여기 중심에는 엔티티 객체라는 것이 있지요. SQL 중심으로 사용할 때는 사실 엔티티 객체라는 것이 거의 없고, 필요한 부분부분 DTO를 만들어서 사용합니다. 이렇게 엔티티 객체라는 것이 명확하게 있는 것과 단순히 데이터를 나열하는 방식은 객체 중심으로 설계를 할 수 있는가 없는가의 큰 차이를 만들어냅니다.

여기에서 오는 큰 장점 중 하나는, 테스트 코드를 자바 코드로 작성하면서, 많은 부분은 테스트 코드로 작성하게 된다는 점입니다. 기존에 SQL에서도 가능하기는 하지만, 중심점이 엔티티 기반의 자바 객체인가, 아니면 SQL 쿼리의 데이터 인가는 테스트 코드를 작성하는데 큰 영향을 미치게 됩니다.

과거에는 단순히 SQL 쿼리를 돌려보고 이 쿼리가 맞구나 하고 mybatis에 등록해서 사용하는 식이었다면, JPA를 사용하면, 엔티티를 중심으로 테스트 코드를 작성하고, JPQL에 대한 검증도 테스트 코드로 하게 되는 것이지요.

그러면 질문하신 부분들에 대한 답을 드릴께요.

1.마이바티스를 사용하면 쿼리를 보자마 판단하기 쉽다. 쿼리를 돌려보려면 결국 애플이케이션을 실행해야 jpql이나 querydsl의 쿼리결과를 볼 수가 있다는거죠.

-> 저도 과거에 이 부분이 좀 걱정되었는데요. 결국 익숙해지니까 JPQL이나, querydsl도 머리속에서 바로 SQL로 전환이 가능합니다(거의 SQL과 똑같으니까요). 그리고 앞서 설명드린 것 처럼 테스트 코드를 이용하기 편하다는 장점도 있습니다. 사실 JPQL을 실행해서 SQL을 뽑아야 sql admin 툴에서 돌려볼 수 있는데요. 이것도 테스트 코드를 실행하면 바로 결과를 뽑을 수 있으니 어렵지 않습니다.

2. 테스트하며 쿼리 작성 후 jpql 맟 querydsl로 변환이 필요없고 바로 파라미터 문법만 바꿔서 복붙하면 된다

-> 이 방법은 SQL을 계속 고쳐가면서 눈으로 검증하는 방법입니다. JPA를 잘 사용하게 되면 자바 코드를 먼저 작성하게 되고, 엔티티 중심으로 테스트 코드로 JPQL이나 Querydsl을 만들고 검증할 수 있게 됩니다. 테스트 코드로 작성을 했기 때문에 향후 누군가 잘못된 변경을 했을 때 쉽게 결과를 확인할 수 있습니다.

사실 이렇게 말씀은 드렸지만, 실무에서는 결국 관계형 데이터베이스를 사용하기 때문에 80:20의 법칙이 존재합니다. 80% 정도는 정말 단순한 쿼리고, 20% 정도는 복잡한 쿼리라는 것이지요.

JPA를 사용하면 80% 정도의 단순한 쿼리들을 매우 편리하게, 나중에 스프링 데이터 JPA와 Querydsl까지 사용하면 거의 작성하지 않아도 될 정도로 정말 편리하고 쉽게 사용할 수 있습니다.

그런데 20% 정도의 복잡한 쿼리들이 남게 되는데, 어느정도는 SQL 툴에서 돌려보고 이걸 JPQL로 작성해야 하는 경우도 있습니다. 그리고 5% 정도의 정말 네이티브 쿼리를 작성해야 하는 경우도 있습니다. 그래서 JPA와 MyBatis나 JdbcTemplate를 함께 사용하는 경우도 있습니다. (물론 JPA가 중심이고, 어쩔 수 없는 네이티브 쿼리를 사용하는 경우에 추가로 사용합니다.)

도움이 되셨길 바래요^^

6

안녕하세요. lbd4946님 활용1편의 테스트 부분을 진행하면서 자연스럽게 배우실 수 있을거에요^^

이후에 테스트를 잘 작성하는 방법은 계속 수련을 하셔야 합니다^^

감사합니다.

1

답변 정말 감사합니다!!! 이렇게 길게 써주시다니 귣굳!!

한가지 이해가 안가는 부분이 있어요

테스트 코드로 검증한다고 하셨는데 이 부분은 해당 강의 목록에는 없는 것 같은데

이는 활용1편을 공부하면서 자연스레 이해가 되는 부분일까요??

스프링 핵심원리도 봤는데 거기서는 DB테스트를 위주가 아니라서 테스트 코드로 검증하기 때문에

1번, 2번 질문의 단점이 해결 된다는게 이해가 될까말까 하네요 ㅎ.ㅎ

감사합니다!!