• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

JPA를 적용시에 서비스 로직 간의 순환 참조 상황에 대해서 질문이 있습니다...

23.02.13 14:15 작성 23.02.13 14:19 수정 조회수 630

0

안녕하세요 김영한 강사님의 강의를 듣고 개인 프로젝트에 JPA를 정말 잘 사용하고 있습니다.

JPA를 사용해서 개발을 하다 보니 JPA를 사용하기 전과 다르게 확실히 객체의 역할을 분리해서 만들 수 있었고 동일 트랜잭션 내에서 영속성 엔티티 객체를 활용하여 DB 통신을 최소화할 수 있었습니다.

그러나 동일한 트랜잭션 내에서 모든 비즈니스 로직을 끝내도록 설계를 하다 보니 서비스 클래스 내에서 다른 서비스 클래스를 사용해야 하는 상황이 빈번히 생겼습니다.

그렇게 무턱대고 서비스 클래스에서 DI를 남용하다 하여 서비스 클래스 간 순환 참조 상황이 벌어지게 되었습니다.

문제를 해결하기 위해 spirng DI 대해서 공부를 하였고 설계가 잘못되었다는 걸 알게 되어 2가지 해결 방법을 생각해 봤습니다.


첫번째 해결방법:

컨트롤러를 거쳐서 순차적으로 서비스 로직을 수행하는 방식이었지만
JPA를 사용하기 때문에 동일한 트랜잭션 내에서 처리하지 않으면 영속성이 해제되어 다시 DB를 참조해야 하는 상황일뿐더러
컨트롤러는 http 파라미터를 검증하고 사용자에게 원하는 정보만 전달한다는 컨트롤러 객체 역할의 기준이 모호해질 것 같았습니다.
컨트롤러에서 트랜잭션을 걸 수 있도록 설정하는 방법을 알아봤지만 위험성이 존재한다고 들었습니다.


두번째 해결방법:

조회만 하는 Service 클래스,
현재 데이터를 검증하여 저장, 변경하는 객체를 실행하는 클래스 등
입출력을 동시에 하는 서비스 객체를 분리하거나
검증하는 과정의 로직을 따로 분리하여 단 방향으로 흐르게 재설계 했습니다.
분리하게 되면서 검증 클래스 같은 경우 추후에 여러 서비스에서 다양한 검증 로직이 필요하게 되면 인터페이스화하여 공통 검증 기능으로 사용할 수 있는 다형성까지 생각해 볼 수 있게 될 것 같아서 현재 이 방법으로 리팩토링하였습니다.


아직 실무를 겪어 보지 못한 취준생이라 제가 해결 한 두번째 방법이 맞는 건지 불안합니다.

아니면 에초에 설계가 잘못되어 다시 구성을 해야 하는 상황일까요??

답변 1

답변을 작성해보세요.

1

안녕하세요. 김영준님

우선 순환참조는 피해야 합니다. 보통 별도의 객체를 만들어서 분리하면 문제가 해결됩니다.

그리고 조회만 하는 서비스는 저도 선호하는 방법입니다.

그리고 이런 방법도 있습니다.

컨트롤러 -> 퍼사드 -> 서비스 -> 리포지토리

서비스를 중간에서 묶어서 처리하는 별도의 계층을 하나 만들어 넣는 것지요.

도움이 되셨길 바래요.

감사합니다.

김프로님의 프로필

김프로

질문자

2023.02.18

설명을 제대로 못 한 것 같아 기대를 안하고 있었는데 이렇게 답글 달아주실 줄은 몰랐습니다 ㅠ

강사님 덕분에 퍼사드 라는 개념을 알게 되었습니다. 알려주셔서 너무 감사합니다!