Repository없이 EntityManager 사용하기

Repository를 사용하지 않을 것을 추천하는 하이버네이트

---

하이버네이트 진영은 Repository를 사용하지 않을 것을 추천합니다. 그 이유를 한 번 알아봅시다.

https://docs.jboss.org/hibernate/orm/6.3/introduction/html_single/Hibernate_Introduction.html#hello-jpa

1. 하이버네이트를 래핑하는 프레임워크는 하이버네이트가 제공하는 세밀한 데이터 제어를 못 하게 한다.
2. JDBC와 하이버네이트는 큰 차이가 있기 때문에 하이버네이트에서 JDBC로 돌아갈 일은 없다.
3. Repository는 스택트레이스를 더 힘들게 하고 디버깅을 힘들게 한다.
4. 대부분의 쿼리는 여러 곳에서 재사용되지 않으므로, 비즈니스 로직에 EntityManager를 사용하는 코드를 넣어도 좋다.
5. repository는 본질적으로 매우 낮은 응집력을 가지고 있다.

저는 이 말이 Spring Data JPA도 포괄한다고 생각합니다. 저는 김영한 님의 JPA 책을 다 읽어보고 든 생각은 Spring Data JPA에 비해서 훨씬 복잡하지만, 잘 사용하지 않는 기능들이 많다고 느꼈습니다. 저는 실무를 하지 않아서 실무 관점으로 생각하지 못합니다. 여러분들의 생각은 어떠하신가요?

 

래핑하는 프레임워크는 일단 하이버네이트의 멋진 점들을 상쇄한다?

---

일단 하이버네이트의 멋진 점인 세밀한 데이터 제어를 어떤 점들에서 제공하는지 알아보고, 정말로 래핑하는 프레임워크가 세밀한 데이터 제어를 방해하는 지 알아보도록 하겠습니다.

 

JPA에선 제공하지만 Spring Data JPA에서 사용할 수 없는 기능들을 딱히 찾아볼 수 없었습니다. 대부분의 경우 JPA를 직접 사용하는 것과 동일하게 혹은 더 쉽게 사용할 수 있었습니다.

 

“리포지토리가 스택트레이스를 더 힘들게 하고 디버깅을 힘들게 한다”라는 말은 동의를 하지만 그 차이가 크지 않은 것 같습니다. 그래서 이 부분도 저에겐 설득력이 없다고 생각됩니다.

 

대부분의 코드는 재사용되지 않는 것이 사실입니다. 그리고 응집도를 낮춘다는 것도 어느정도 공감이 됩니다. 그래서 이 부분은 뭘 하든 크게 차이가 없다고 느껴집니다. 저는 개인적으로 jpql이 밖으로 드러나와 있으면 코드가 한눈에 들어오지 못한다고 생각해서 메소드로 분리하는 것이 좋다고 생각합니다.

이정도 차이라고 느껴졌습니다. 조금 답답했던 점은 orElseThrow와 Pagenation 지원과 saveAll의 부재 정도였습니다.

 

Spring Data JPA 쓰는게 더 장점이 많다

---

Spring Data JPA의 간편함을 포기하기엔 JPA를 바로 쓰는 것의 장점이 크다고 느껴지지 않았습니다.

1. 쿼리가 구현 단에 보임
2. orElseThrow 불가
3. Optional 불가
4. 페이지네이션 불가

등등의 자잘한 불편함이 있었고, 웬만한 기능들은 다 사용할 수 있다고 느꼈기 때문에 Spring Data JPA를 사용하는 것이 대부분의 상황에서 유리하다고 생각했습니다. 여러분들의 생각은 어떠하신가요?