DTO를 각 요청마다 분리해야하는 이유

DTO에 대해 처음 공부했을 때 각 요청마다 DTO를 분리하는 이유가 단순히 로직 수행에 필요없는 데이터가 dto 객체에 같이 돌아다니기 때문이라고 생각했다.

하지만 시간이 지나 @Validated와 BindingResult 등 검증에 대해 공부하다보니 , 위와 같은 이유도 분명히 있지만 왜 각 요청마다 DTO를 분리해야하는지 깨닫게 되었다.

Item이라는 객체가 있고, 그 item을 저장하는 요청과 업데이트하는 로직이 있다고 가정하고 각 케이스에 대해 알아보자.

DTO 분리 전

@Data
public class Item {
    private Long id;
    private String itemName;
	private Integer price;
    private Integer quantity;
}

위와 같은 Item 객체가 있다고 했을 때

저장하는 로직에 사용되는 필드 변수들은 itemName, price, quantity이고, 수정에 필요한 필드는 id, itemName, price, quantity라고 가정하자. (저장할 때는 sequence로 id 지정)

그리고 상품 저장 시 다음과 같은 요구사항을 적용시키자.

• 상품 가격은 1000원 이상
• 상품 수량은 9999개 이하

그럼 다음과 같이 Bean Validation를 적용시킬 수 있을 것이다.

@Data
public class Item {
    private Long id;
    private String itemName;
	@Min(1000)
    private Integer price;
    @Max(9999)
    private Integer quantity;
}

근데 여기서 다음과 같은 요구사항이 추가되었다.

• 수정 시 수량을 무제한으로 풀기

이때 문제가 발생한다.

상품 저장과 수정 모두에 Item 객체를 사용하고 있기 때문에 요구사항이 변경되면서 두 요청의 검증 조건이 서로 달라 Item 객체를 그대로 사용할 수 없다.

이런 문제를 해결하기 위해 DTO를 분리해야한다.

DTO 분리

@Data
public class ItemSaveDto {
    private String itemName;
	@Min(1000)
    private Integer price;
    @Max(9999)
    private Integer quantity;
}

@Data
public class ItemUpdateDto {
    private Long id;
    private String itemName;
	@Min(1000)
    private Integer price;
    private Integer quantity;
}

이런 문제를 해결하기 위해 위 코드와 같이 ItemSaveDto와 ItemUpdateDto로 각 요청에 알맞는 DTO를 생성해주면 된다.

이로써 Save시 필요한 데이터와 검증 조건을 적절히 설정할 수 있고, Update시 수량의 검증 조건을 빼 요구사항을 잘 충족시킬 수 있다.