국민학교 프로젝트를 리팩토링하면서 DTO를 Entity로 변환하는 최적의 위치에 대한 고민이 들었습니다. 이 의문을 해결하기 위해, 우선적으로 엔티티를 서비스 계층에서만 사용하는 것과 엔티티를 모든 계층에서 사용하는 것의 차이를 고려해야 합니다.
Controller?
xxDto found = xxService.findById(id);
xx foundToEntity = xxDto.toEntity();위의 코드가 컨트롤러에 있을 때, xxService, xxDto, xxEntity 모두에 의존하게 되면서 코드의 의존성이 복잡해질 수 있습니다. 이러한 상황은 바람직하지 않습니다.
반면, 컨트롤러에서 xxEntity entity = xxService.findById(id)와 같은 코드를 사용하면, 컨트롤러는 xxService와 xxEntity에만 의존하게 되며, xxDto에 대한 의존성은 낮아집니다. 또한, xxDto found = xxService.findById(id)와 같이 xxDto만을 반환받는다면, 컨트롤러는 xxDto와 xxService에만 의존하게 되며, xxEntity는 서비스 계층을 통해서만 접근하게 됩니다. 이렇게 하면 xxEntity를 외부에 공개하지 않게 되어 코드의 캡슐화와 유지보수성이 개선됩니다.
Service
xxEntity entity = xxDto.toEntity();Service는 비즈니스 로직을 처리하는 주요 계층입니다. 따라서 DTO와 Entity 간의 변환 작업을 Service에서 수행하는 것이 좋습니다. 이렇게 하면 xxEntity와 xxDto에 대한 의존성을 관리할 수 있으며, 변환 로직을 중앙 집중화할 수 있습니다. 이 접근 방식은 코드 중복을 줄이는 데에도 도움이 됩니다.
Service에서 변환 작업을 처리함으로써 비즈니스 로직과 프레젠테이션 로직이 분리됩니다. 이로 인해 Controller와 Service 간의 책임이 명확해지고, 각 계층이 자신의 책임에 집중할 수 있습니다. 이러한 구조는 단일 책임 원칙을 준수하는 데도 기여하며, 코드의 유지보수성과 가독성을 향상시킵니다.
또한, Service 계층에서만 Entity를 사용하는 것이 좋습니다. 영속성 컨텍스트는 트랜잭션이 시작될 때 같이 시작되고, 트랜잭션이 끝날 때 영속성 컨텍스트도 같이 종료됩니다. 이는 영속성 컨텍스트의 범위 내에서 지연 로딩을 지원하기 때문입니다. 반면, Controller에서는 트랜잭션이 끝난 시점에 영속성 컨텍스트가 종료되므로, 지연 로딩이 불가능합니다. 따라서, Entity는 Service 계층 내에서만 사용하여 이러한 문제를 방지하는 것이 좋습니다.
결론
엔티티와 DTO의 사용은 전체 시스템 구조에서 중요한 고려사항입니다. DTO를 단순한 데이터 전송 객체로 취급하고, DTO의 위치와 의존관계를 신중하게 설계하는 것이 필요합니다. Controller와 Service에서 변환 작업을 수행하는 것에는 각각 장단점이 있으며, 프로젝트의 구조와 성격에 따라 적절한 선택이 필요합니다. 이 과정에서 엔티티와 DTO의 적절한 사용 및 위치 배치를 통해 시스템의 효율성과 유지보수성을 높일 수 있습니다.
📚 참고자료
