트레이드 오프
구조를 정석적으로 지킬 때 장점이 있는 것은 사실이다.
유지보수 관점에서 인터페이스의 변경없이 구현체만 변경하면 되고,
객체지향 원칙도 지킬 수 있다.
다만 무조건적으로 좋은 점만 있는 것은 아니다.
구조를 지킨다는 것은 그만큼 관리해야할 것이 많다는 뜻이다.
컨트롤러를 사용할 때 서비스의 메소드 하나 호출하는 것도 구조가 많이 복잡해진다.
서비스는 인터페이스로 만들 것이고, 컨트롤러에서 서비스의 메소드를 호출하면 그 구현체를 찾을 것이고,
그 서비스의 구현체에서는 리포지토리를 찾을 것인데,
거기서는 또 리포지토리의 인터페이스를 참조할 것이고,
그 인터페이스는 또 구현체가 있을 것이며,
스프링 데이터 JPA를 사용한다면 또 그 리포지토리 인터페이스는 JpaRepository를 참조할 것이다.
너무나도 복잡한 구조다.
그래서 우리는 트레이드 오프라는 것을 확인한다.
이 경우에는 서비스가 바로 스프링 데이터 JPA를 사용하게 하는 것일거다.
사실상 개발할 때의 트레이드 오프는 이 애플리케이션의 중점은
구조의 안정성이냐 아니면 단순한 구조와 개발의 편리성이냐가 될 것이다.
분명한 정답은 없다. 왜냐하면 개발자마다 상황이 다르고, 애플리케이션마다 상황이 또 다르기 때문이다.
그래서 추상화 비용을 넘어설 만큼 효과가 있다!라고 판단할 때만 추상화를 적용하는 것이 좋다.
유지보수 관점에서 봤을 때 추상화하는 것도 비용이고 별도로 인터페이스를 만드는 것도 비용이다.
현재 상황에 맞는 선택을 하는 개발자가 되자.
다양한 데이터 접근 기술 조합
데이터 접근 기술에 정답은 없다.
비즈니스 상황과 프로젝트 구성원의 역량에 따라서 결정해야 한다.
경우에 따라 섞어 쓰는 것이 좋을 때가 있고, 아니면 하나만 쓰는 것이 좋을 때도 있으며,
아주 드물게는 프로젝트 자체를 성격에 따라 여러 개로 나누는 케이스도 있다.
요즘에는 베이스는 JPA, 스프링 데이터 JPA, QueryDSL 이 3개를 베이스로 진행하되,
통계같이 복잡한 쿼리에는 JdbcTemplate이나 MyBatis를 쓰는 것이 추세이긴 하다.
하지만 이것은 절대적인 것은 아니기에 잘 알아보고 결정하자.
다만 이제 섞어 쓰는 경우에는 주의해야할 사항이 있는데
JPA는 기본적으로 플러시를 하지 않는 이상은 트랜잭션이 종료되어야지 DB에 반영된다.
그래서 하나의 메소드 안에서 JPA와 JdbcTemplate을 같이 쓰면 JdbcTemplate이 변경된 데이터를 감지하지 못 하는 경우가 있다.
이런 경우에는 JPA가 제공하는 플러시라는 기능을 통해서 즉각 반영시켜야 하는 것을 잊지 말자.