221229 Spring JPA
스프링 데이터 JPA와 트레이드 오프
 인터페이스에 의존하도록 만들어서 Repository를 교체하여도 Service의 코드는 수정을 하지 않아도 되었다.
고민 : 구조를 맞추기 위해서는 중간에 어댑터가 들어가면서 전체 구조가 너무 복잡해지고 사용하는 클래스도 많아지는 단점이 생김.  DI OCP원칙을 포기하는 대신에 복잡한 어댑터를 제거하고 구조를 단순하게 가져올 수 있는 장점
즉.. 이 두가지는 트레이드 오프 관계
- Di OCP를 지키기 위해 어댑터를 도입하고 더 많은 코드를 유지
- 어댑터를 제거하고 구조를 단순하게 가져가지만 DI OCP를 포기 Itemservice코드 직접 변경
개발을 할 때 자원이 무한한 것이 아닌다. “어설픈 추상화”는 오히려 독이 된다. “추상화도 비용이 든다” 여기서의 비용은 유지보수 관점에서 비용, 이 추상화 비용을 넘어설 만큼 효과가 있을 때 추상화 도입이 실용적
이런 선택은 정답이 없다 하지만 현재 상황에 맞는 선택을 하는 개발자가 되어야겠.다.
———————————————  이러한 구조로 스프링 데이터 JPA의 기능은 최대한 살리면서 Querydsl도 편리하게 사용할 수 있도록 두 구조를 나눠서 필요하면 불러오는 구조이다.
————————————————— 다양한 데이터 접근 기술 조합.
비즈니스 상황과 현재 프로젝트 구성원의 역량에 따라서 결정하는 것이 맞다…. JdbcTemplate, MyBatis 같은 기술들은 SQL을 직접 작성해야 하는 단점이 있지만. 기술이 단순하기 때문에 SQL에 익숙한 개발자라면 금방 적용할 수 있다. JPA, 스프링 데이터 JPA, QueryyDSL같은 기술은 개발 생산성을 혁신할 수 있지만, 학습 곡선이 높기 떄문에 이런 부분을 감안해야 한다… 그리고 매우 복잡한 통계 쿼리를 주로 작성하는 경우 맞지가 않는다.
JPA, 스프링 데이터 JPA, Querydsl을 기본으로 사용하고 복잡한 쿼리를 사용해야 하면 JdbcTemplate, MyBatis를 함께 사용..! 실무에서 95% JPA, 스프링 데이터 JPA, Querydsl로 해결 가능..
- 트랜잭션 매니저 선택 JPA, 스프링 데이터 JPA, Querydsl는 모두 JPA 기술을 사용하는 것이기 때문에 트랜잭션 매니저로 “JPATransactionManager”선택 따라서 JPA, JdbcTemplate를 둘 다 사용하면 트랜잭션 매니저를 두개 사용하게 된다. 하지만… 다양한 지원이 가능하여 달 다 사용 가능하다.. 결과적으로 JpaTransactionManager를 하나만 스프링 빈에 등록하면 JPA, JdbcTemplate,Mybatis 모두를 하나의 트랜잭션으로 묶어서 사용 가능
— 주의점 (둘 다 사용하였을 경우) 주의점 이렇게 JPA와 JdbcTemplate을 함께 사용할 경우 JPA의 플러시 타이밍에 주의해야 한다. JPA는 데이터를 변경하면 변경 사항을 즉시 데이터베이스에 반영하지 않는다. 기본적으로 트랜잭션이 커밋되는 시점에 변경 사항을 데이터베이스에 반영한다. 그래서 하나의 트랜잭션 안에서 JPA를 통해 데이터를 변경한 다음에 JdbcTemplate을 호출하는 경우 JdbcTemplate에서는 JPA가 변경한 데이터를 읽기 못하는 문제가 발생한다. 이 문제를 해결하려면 JPA 호출이 끝난 시점에 JPA가 제공하는 플러시라는 기능을 사용해서 JPA의 변경 내역을 데이터베이스에 반영해주어야 한다. 그래야 그 다음에 호출되는 JdbcTemplate에서 JPA가 반영한 데이터를 사용할 수 있다.