스프링 DB 2편 - 데이터 접근 핵심 원리 - 섹션8. 데이터 접근 기술 - 활용 방안

 

 

이건 가치관과 의견 차이에 대한 이야기인데, 이미 JpaRepository 자체가 알아서 잘 하고 있고 분리해서 만들기 위해 내가 사용할 Repository를 만들어서 JpaRepository를 상속해서 만드는데 어차피 JpaRepository를 사용하니 굳이 만들지 말고 서비스에서 바로 사용하는게 어떻겠느냐이다.

내가 JpaRepository를 상속하는용 레퍼지토리를 만들어서 사용하면 DB를 바꾸거나 하는데 더 간편하게 바꿀 수 있겠지만 사실 DB를 바꾸거나 할 일은 굳이 많지 않고 코드가 인터페이스 하나를 더 들어가야 해서 분석하는데 괜히 복잡해진다. 그럴바엔 그냥 서비스에서 바로 쓰는게 더 좋지 않느냐. 근데 서비스에서 바로 쓰면 안의 내용이 바뀌거나 하면 다 바뀌어야 해서 이것도 애매하다.

 

결론은 상황 및 내가 사용하고 싶은거에 따라 달린거임. 일단 빨리 만들기 위해 서비스에서 바로 JpaRepository를 사용하다가 프로젝트가 점점 커져서 따로 만들어야 할 때가 오면 그때 바꾸는 걸 추천함.

 

이렇게 한번 사용해보기

 

JpaRepository를 상속하면 자동으로 빈에 등록되서 @Repository 안해도 된다.

 

일단 빨리빨리 개발한 뒤 나중에 필요해질 때 리팩토링 하는것도 좋은 방법이다.

 

정리하면 직접 접근하는건 JdbcTemplate나 Mybatis가 있고 객체로 사용하는 JPA와 그 도우미들인 스프링 데이터 JPA, Querydsl이 있다. JPA가 워낙 혁신이라 mybatis같은걸 사용한다 해도 거의 95%, 5% 정도의 비율로 사용하게 될 것. 진짜 복잡한 통계용 쿼리를 얼마나 사용하느냐에 따라 조금씩 달라진다.

근데 트랜잭션 매니저가 Jpa는 JpaTransactionManager를 사용하고 직접 사용하는 JdbcTemplate나 mybatis는 DataSourceTransactionManager를 사용할텐데 만약 두개 다 사요하면 어떻게 되냐? 사실 JpaTransactionManager가 DataSourceTransactionManager를 상속해서 만들어진거라 제공하는 기능을 대부분 제공해서 함께 사용하는건 문제가 안된다. 주의점은 JPA의 플러시 타이밍이라는게 있는데 JPA는 트랜잭션이 커밋되는 시점에 변경사항을 데이터베이스에 반영해서 jdbcTemplate같은 애는 반영 되지 않은 데이터베이스를 읽을 수 있다는 것. 그래서 코드에서 강제로 플러시 기능을 사용해서 변경 내용을 데이터베이스에 반영해주면 된다. 이건 나중에 배울 것.