스프링 데이터 JPA와 트레이드 오프

스프링 데이터 JPA

• 구조를 맞추기 위해, 중간에 어댑터가 들어가면서 전체 구조가 너무 복잡해지고 사용하는 클래스도 많아지는 단점이 생겼다.
• 유지보수 관점에서 ItemRepository의 구현체를 변경할 수 있는 장점이 있다.
  • DI, OCP 원칙을 지킬 수 있다는 좋은 점이 분명히 있다.
  • 반대로 구조가 복잡해지면서 어댑터 코드와 실제 코드까지 함께 유지보수 해야하는 어려움도 발생한다.

다른 선택

• 직접 스프링 데이터 JPA를 사용하는 방법
• DI, OCP 원칙을 포기하는 대신, 복잡한 어댑터를 제거하고, 구조를 단순하게 가져갈 수 있는 장점이 있다.
• 클래스 의존 관계

• 런타임 객체 의존 관계

트레이드 오프

• DI, OCP를 지키기 위해 어댑터를 도입하고, 더 많은 코드를 유지함
• 어댑터를 제거하고 구조를 단순하게 가져가지만 DI, OCP를 포기하고, 서비스 코드를 직접 변경함

→ 구조의 안전성 vs 개발의 편리성

• 상황마다 중요한 게 달라질 수 있다.
• 개발할 때 항상 자원이 무한한 것은 아니기에 어설픈 추상화는 오히려 독이 되는 경우도 많음
• 추상화도 비용이 든다! 인터페이스도 비용이 든다!
  • 비용: 유지보수 관점에서 비용
• 추상화 비용을 넘어설만큼 효과가 있을 때 추상화를 도입하는 것이 실용적임

 

🌟 현재 상황에 맞는 선택하는 게 중요하다!