[Spring] 서비스를 통한 데이터 접근 vs 레포지토리 직접 접근

프로젝트를 진행하다가 데이터베이스의 다른 테이블에 접근하는 일이 필요할 때,

 

관련 서비스를 통해서 레포지토리를 통해 접근,

혹은 사용중인 서비스에서 레포지토리를 바로 호출해서 접근.

 

이 두 가지 접근에 대해 의견이 나눠졌다.

 

그래서 각각의 방법이 가진 특성과 그로 인한 장단점을 조사해봤다.

 

 

A 서비스가 B 서비스를 거쳐 B 레포지토리에 접근하는 방식

이 방법은 서비스 계층의 캡슐화와 추상화를 잘 유지하면서 다른 도메인의 로직에 손쉽게 접근할 수 있도록 해준다.

B 서비스는 B 테이블의 비즈니스 로직을 담당하며, A 서비스는 B 서비스가 제공하는 인터페이스를 통해 필요한 로직을 재사용할 수 있다.

 

장점:

1) 코드 재사용성의 증가

B 테이블과 관련된 비즈니스 로직이 B 서비스에 집중되어 있어, 다른 서비스에서도 필요할 때 쉽게 재사용할 수 있다.

 

2) 결합도의 감소

A 서비스는 B 레포지토리의 내부 구현을 몰라도 되므로, B의 변경사항이 A에 미치는 영향을 최소화할 수 있다.

 

3) 단일 책임 원칙의 준수

각 서비스가 자신의 도메인에만 초점을 맞추어 코드의 유지보수성과 가독성을 높일 수 있다.

 

단점:

간접 호출로 인한 오버헤드 발생 가능성: 간혹 서비스 계층을 통하는 것이 직접 레포지토리에 접근하는 것보다 복잡하거나 미세한 성능 저하를 초래할 수 있다.

 

A 서비스가 B 레포지토리에 직접 접근하는 방식

이 방법에서는 A 서비스가 B 레포지토리의 메소드를 직접 호출하여 데이터를 조회하거나 변경한다. 빠른 개발이 필요하거나 로직이 매우 간단한 경우에 유리할 수 있다.

 

장점:

간단한 로직의 신속한 처리

아주 간단한 CRUD 작업 같은 경우, 서비스 계층을 건너뛰고 바로 레포지토리에 접근하는 것이 코드를 더 단순하게 만들 수 있다.

 

단점:

1) 코드 중복의 위험

B 테이블과 관련된 비즈니스 로직이 여러 서비스에 걸쳐 중복되어, 유지보수가 어려워질 수 있다.

 

2) 결합도의 증가

A 서비스가 B 레포지토리의 내부 구현에 의존하게 되어, B에서의 변경사항이 A에 큰 영향을 미칠 수 있다.

 

3) 비즈니스 로직의 분산

비즈니스 로직이 서비스 계층과 레포지토리 계층에 걸쳐퍼져 있어, 전체 시스템의 구조를 파악하기 어려워질 수 있다.

 

마무리와 결론

결론적으로, 다른 도메인의 데이터나 로직에 접근할 때는 대체로 서비스 계층을 통하는 것이 좋다고 할 수 있다.

이 방식은 시스템의 유지보수성을 높이고, 코드의 재사용성을 증가시키며,

각 계층의 역할을 분명히 해줌으로써 많은 이점을 제공한다.

 

물론 상황에 따라 직접 레포지토리에 접근하는 방식을 선택할 수도 있겠지만,

그럴 경우에도 각 방식의 장단점을 충분히 고려하는 것이 중요하다.