스프링 DB 데이터접근 기술 - 활용 방안

* 트레이드 오프 *

- DI, OCP를 지키기 위해 어댑터를 도입하고, 더 많은 코드를 유지한다

- 어댑터를 제거하고 구조를 단순하게 가져가지만, DI, OCP를 포기하고 서비스 코드를 직접 변경한다.

 

- 결국 여기서 발생하는 트레이드 오프는 구조의 안전성 vs 단순한 구조와 개발의 편리성 사이의 선택

-  개발을 할 때는 항상 자원이 무한한 것이 아니다. 그리고 어설픈 추상화는 오히려 독이 되는 경우도 많다. 무엇보다 *추상화도 비용이 든다.* 인터페이스도 비용이 든다. 여기서 말하는 비용은 유지보수 관점에서 비용을 뜻한다. 이 추상화 비용을 넘어설 만큼 효과가 있을 때 추상화를 도입하는 것이 실용적이다

 

 

* 실용적인 구조 *

- 기본 CRUD와 단순 조회는 스프링 데이터 JPA가 담당하고, 복잡한 조회 쿼리는 Querydsl이 담당하게된다.

 

* 참고 *

- 스프링 데이터 JPA가 제공하는 커스텀 리포지토리를 사용해도 비슷하게 문제 해결 가능

 

---

다양한 데이터 접근 기술 조합

- `JdbcTemplate` 이나 `MyBatis` 같은 기술들은 SQL을 직접 작성해야 하는 단점은 있지만 기술이 단순하기 때문에 SQL에 익숙한 개발자라면 금방 적응

- JPA, 스프링데이터 JPA, Querydsl 같은 기술들은 개발 생산성을 혁신할 수 있지만, 학습 곡선이 높기 때문에 감안할 것

   매우 복잡한 통계 쿼리를 주로 작성하는 경우 잘 맞지 않는다.

 

- 추천 방향은 JPA, 스프링 데이터 JPA, Querydsl을 기본으로 사용하고, 만약 복잡한 쿼리를 써야 하는데, 해결이 잘 안되면 해당 부분에는 JdbcTemplate이나 MyBatis를 함께 사용하는 것이다.

 

* 트랜잭션 매니저 선택 *

- JPA, 스프링데이터 JPA, Querydsl은 모두 JPA 기술을 사용하는 것이기 때문에 트랜잭션 매니저로 `JpaTransactionManager`를 선택하면 된다.

- 해당기술을 사용하면 스프링 부트는 자동으로 `JpaTransactionManager`를 스프링 빈에 등록한다

- 그런데 `JdbcTemplate`, `MyBatis`와 같은 기술들은 내부에서 JDBC를 직접 사용하기 때문에 `DataSourceTransactionManager`를 사용한다

- 따라서 JPA와 JdbcTemplate 두 기술을 함께 사용하면 트랜잭션 매니저가 달라진다.

 

* JpaTransactionManager의 다양한 지원 *

- `JpaTransactionManager` 은 놀랍게도 `DataSourceTransactionManager`가 제공하는 기능도 대부분 제공한다.

- JPA라는 기술도 결국 내부에서 DataSource와 JDBC 커넥션을 하기 때문이다.

- 따라서 `JdbcTemplate`, `MyBatis`와 함께 사용할 수 있다

- 결과적으로  `JpaTransactionManager` 를 하나만 스프링 빈에 등록하면, JPA, JdbcTemplate, MyBatis 모두를 하나의 트랜잭션으로 묶어서 사용할 수 있다.

- 물론 함께 롤백도 할 수 있다

 

* 주의점 *

- JPA와 JdbcTemplate를 함께 사용할 경우 JPA의 플러시 타이밍에 주의해야 한다.

- JPA는 데이터를 변경하면 변경 사항을 즉시 데이터베이스에 반영하지 않는다.

- 기본적으로 트랜잭션이 커밋되는 시점에 변경 사항을 데이터베이스에 반영한다.

- 그래서 하나의 트랜잭션안에서 JPA를 통해 데이터를 변경한 다음에 JdbcTemplate을 호출하는 경우

   JdbcTemplate에서는 JPA가 변경한 데이터를 읽지 못하는 문제가 있다.

- 이 문제를 해결하려면 JPA 호출이 끝난 시점에 JPA가 제공하는 플러시라는 기능을 사용해서 JPA의 변경 내역을

   데이터베이스에 반영해주어야 한다.

- 그래야 그 다음에 호출되는 JdbcTemplate에서 JPA가 반영한 데이터를 사용할 수 있다.