데이터 전송 시 DTO vs Map카테고리 없음2024. 6. 9. 20:45
Table of Contents
개발을 하는 도중 Controller에서 데이터를 주고 받을 때, 각 요청 별 DTO를 다 만드는 것이 좋을까? 아니면 객체를 많이 만들 필요없이 Map을 사용하는 것이 더 좋을까?에 대한 고민이 생겨 찾아본 내용을 정리할려고 한다.
Map
장점
- 요청에 대해서 별도의 클래스를 만들 필요가 없어서, 관리할 클래스 파일이 줄어든다.
- 받아야될 데이터가 수정되더라도 클래스를 수정할 필요 없이 간단하게 변경할 수 있다.
- 클래스를 만들 필요가 없으니 초기에는 작업 시간이 단축된다.
단점
- 요청 데이터의 정합성을 검증하기 힘들다.
- 내부 코드를 읽어봐야 어떤 데이터를 주고 받는지 알 수 있다.
- 검증 로직의 위치가 애매해진다.
- 별도의 타입 캐스팅 로직이 추가된다.
DTO
장점
- 클래스 명으로 더 명확하게 객체의 역할을 표현할 수 있다.
- 어떤 데이터를 요구하는지 확인하기 편하다.
- 각 요청에 맞는 검증 로직을 클래스 내에서 작성하여 응집도를 높일 수 있다.
- 타입 체크가 편리하고 별도의 타입 캐스팅이 필요없다.
단점
- 각 요청에 대응하는 너무 많은 클래스가 생기게된다. 즉, 관리 대상이 많아진다.
너무 많은 DTO 클래스가 생성되는 문제를 해결하는 방법
범용 DTO를 만들 경우 어떤 데이터를 필요로 하는지 역할이 무엇인지 명확하게 해준다는 장점이 의미가 없기 때문에 각 요청 별로 객체를 만들되 그 객체들을 하나의 파일에서 관리할 수 있도록 InnerClass를 활용해서 하나의 DTO 내부에 그 DTO의 요청 별 DTO를 작성하면 문제를 해결할 수 있다.
이렇게 하면 결과적으로 DTO를 사용하는 것이 Map을 사용하는 것 보다 큰 장점을 가진다.
public class SampleDto {
@Getter
@Setter
public static class Create {
private String content;
@Builder
public Create(String content) {
...
}
}
@Getter
@Setter
public static class Update {
private Long id;
private String content;
...
}
@Getter
@Setter
public static class Response {
private Long id;
private String content;
private String file;
private Long userId;
...
public static Response of(Sample sample) {
final Response dto = modelMapper.map(sample, Response.class);
...
return dto;
}
public static List<Response> of(List<Sample> sampleList) {
return sampleAskList.stream()
.map(Response::of)
.collect(Collectors.toList());
}
}
}
Reference
@뽀글뽀글 개발자 :: 뽀글뽀글 개발 일지
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!