파트장님께서 보내준 아티클 정리 및 생각 정리.

개요

JPA/Hibernate를 버리세요 라는 자극적인 제목의 글.

SQL 은 배우기 쉽지만 JPA/Hibernate 는 학습 비용 발생
몇가지 뻣뻣한 점
- 객체 속성을 강제로 공개해야 하는 부분
Lazy loading, Open in view 등 프록시 메커니즘에서 발생하는 초심자 트랩.
Flush 의 존재로 다른 영속성 도구를 사용할 수 없다 (?)
- 이건 무슨 이야긴지 모르겠음.
특정 컬럼만 보려면 projection 등 한층 복잡해짐.
Constraint 가 ORM 과정 전체에 종속됨
- 예를 들면 @Email 같은 어노테이션을 활용하면 유닛테스트에는 ORM 에서 잘 처리해줬을거라 가정하고 테스트 하게 됨.
디폴트 옵션들이 별로인 경우가 많다.
- Open in view 가 n+1 쿼리를 발생할 여지 있음.
- 기본 ID 보다 UUID 사용이 더 나음.

반론

분명 학습 비용이 있지만 생산성에 기여하는 부분이 있긴 하다.
- 쿼리가 조금만 복잡해져도 SQL 작성하는데 하루종일 걸리고, SQL injection, 트랜잭션 같은 장치를 새로 개발해줘야 한다.
- 초기 DB 스키마 작업시 column name 등을 쉽게 바꿀 수 있는 점은 장점중 하나다.
한국 JAVA 생태계에선 사실상 스프링 JPA 는 기본기 같은 느낌
JPA 에서 제대로 지원하지 못하는 쿼리에 대해선 OK 지만, 이 경우엔 SpringDataJDBC, MyBatis, JOOQ 같은 옵션들이 있음.
- Hibernate 의 경우 FROM subquery 를 지원하지 않는 버전이 있다. (6.x 미만인가 그럴거임.)
날 쿼리를 직접 날리는 경우는 relation 이 많이 복잡하지 않은 간단한 DB 일 땐 좋을수도 있겠다.
JPA 에서 지원안해서 못해요 → 이런 상황은 없어야 하니 dynamic한 날 쿼리를 직접 날리는 것도 할 줄은 알아야 한다.

최근 회사에서 논의된 JPA 의 오버헤드도 나름 치명적인 단점으로 보인다. few ms 짜리 쿼리인데 JPA 의 오버헤드는 10 ms 정도 되는 경우도 있어서.