JPA의 순환참조이슈에 처음 걸려봤고
당연하게 아래 설명한 애노테이션으로 해결했지만
근본적인 해결책은 아니란걸 봤고
Entity를 직접적으로 리턴하는 것 자체에 큰 문제가 있다는걸 깨달았다.
그 내용에 대해 간략히 다뤄보고자 한다.
JPA의 순환참조 이슈를 해결하기 위해서 아주 쉬운 방법이 있다.
@JsonBackReference
@JsonManagedReference직렬화 방향을 설정해 서로간의 참조를 발생하지 않도록 방어해주는 어노테이션이다.
아주 간편하지만, 근본적인 해결책이 되지 못한다.
근본적으로 JPA의 순환 참조 문제는 Entity를 직접 return하는데에서 비롯된다.
Entity를 직접 반환한다면
- Entity구조 변경 시 문제 발생
요구사항이 변경되어 엔티티의 필드 이름이 변경 될 경우? API 스펙이 변경되어 추가 작업이 요구된다. 이는 효과적인 유지보수와 멀어지는 길이다. - 필요한 데이터만 전송하기 어렵다
엔티티를 직접 반환하면 존재하는 모든 데이터가 반환되기 때문에
불필요한 데이터를 사용자에게 전달할 가능성이 생기고, 성능적으로도 옳지 못하다. - 순환 참조 문제
엔티티 간 양방향 관계가 존재 할 경우, 엔티티를 반환하는 순간 순환 참조로 인한 무한 JSON 직렬화 이슈를 맞게된다. - 보안 문제
Entity 반환 == 테이블 공개이다.
이렇듯, Entity를 직접 분리하는 작업은 위험하다.
DTO와 Entity를 분리한다면
- View와 Model의 분리(MVC패턴)
DTO는 View와 Controller의 역할을, Entity는 Model의 역할을 한다. - 필요한 데이터만 선별하여 서버 사용량 최소화
DTO는 필요한 필드만 재정의하여 사용하면 된다. - 엔티티 구조가 변경되어도 안전
엔티티 구조가 변경되더라도 DTO를 사용하여 데이터 전송을 처리하면 이 변경 사항이 클라이언트에 직접적으로 영향을 미치지 않는다. - 순환 참조 예방
DTO는 엔티티 간의 양방향 참조가 포함되지 않는 간단한 구조를 갖는다. - Validation 코드와 모델링 코드 분리
@NotNull, @NotEmpty, @NotBlank 등의 valitaion 코드와 @Column, @ManyToOne 등의 모델링 코드를 분리할 수 있다. DTO에서 validation을 하면 Entity는 모델링에 집중할 수 있다.
사진 출처: "참고한 포스팅" 링크
