[Spring] 객체 지향적으로 DTO 변환하기 (2)

[Spring] 객체 지향적으로 DTO 변환하기 (1) 글에서 이어지는 내용입니다.

그 전의 글에서는 DTO 에 변환 로직을 추가해 서비스 코드에서 변환 로직을 제거할 수 있었다. 하지만 이는 DTO 가 Entity 를 의존하는 문제가 발생한다.

객체 지향 프로그래밍의 핵심 원칙 중 하나는 단일 책임 원칙이다. 위의 방법은 Dto 가 데이터 전송의 역할뿐만 아니라 데이터 변환 역할도 하고 있다.

이를 해결하기 위해 별도의 클래스에 변환 로직을 정의해 사용하기로 하였다.

추가로 나중에 변환 로직을 사용하는 구현체가 변경될 수 있으므로 인터페이스로 정의한 뒤 Spring 을 통한 구현체를 주입받는다.

TranslationService

너무 코드가 기므로 전의 글에서 사용했던 Choice 에 대해서만 보겠다.

public interface TranslationService {

    ChoiceDetailDto entityToDto(Choice choice);

    Choice DtoToEntity(ChoiceRequestDto choiceRequestDto, QuestionDocument questionDocument);
}

TranslationServiceImpl

@Override
public ChoiceDetailDto entityToDto(Choice choice) {
	return ChoiceDetailDto.builder()
    	.id(choice.getId())
		.title(choice.getTitle())
        .count(choice.getCount())
        .build();
}

@Override
public Choice DtoToEntity(ChoiceRequestDto choiceRequestDto, QuestionDocument questionDocument) {
	return Choice.builder()
    	.questionDocument(questionDocument)
        .title(choiceRequestDto.getChoiceName())
        .count(0)
        .build();
}

서비스 계층에서의 변경

public ChoiceDetailDto getChoice(Long choiceId) {
	return translationService.entityToDto(
    		choiceRepository.findById(choiceId)
            		.orElseThrow(() -> new NotFoundException("선택지")));
}

전의 Dto 내부에 변환 로직을 정의했을 때와 서비스 계층에서 코드는 변화가 많이 없다. 하지만 이제 Dto 는 오직 Dto 의 역할인 데이터 전송 역할에 집중할 수 있게 되었고, 서비스 계층 또한, 비즈니스 로직에 집중할 수 있게 되었다.