이번 강의는
“DTO를 언제, 왜, 어떻게 나누어 써야 하는지”가 아주 명확하게 정리된 강의였다.
이전까지는 DTO를 만들긴 했지만
이게 언제 필요한지
어디까지 만들어야 하는지
안 만들어도 되는 경우는 언제인지
가 좀 애매했는데,
30강에서 이 기준이 깔끔하게 정리됐다.
핵심 목적은 딱 하나다.
엔티티를 그대로 외부에 노출하지 않고
상황에 맞는 “형태”로만 데이터를 전달하기 위해서
이를 위해 DTO는 크게 4가지 역할로 나뉜다.
RsData<Void>
{
"resultCode": "200-1",
"msg": "삭제되었습니다.",
"data": null
}
RsData<PostDto>
{
"resultCode": "200-1",
"msg": "조회 성공",
"data": {
"id": 1,
"title": "제목"
}
}
RsData<List<PostDto>>
RsData<PostWriteResBody>
{
"resultCode": "201-1",
"msg": "글이 작성되었습니다.",
"data": {
"totalCount": 10,
"post": {
"id": 10,
"title": "제목",
"content": "내용"
}
}
}
👉 이 경우에는 전용 ResBody DTO를 만든다.
data는 항상 하나PostDto
MemberDto
예)
PostDto
- id
- 날짜
- 제목
MemberDto
- id
- 날짜
- 권한
PostWithContentDto
MemberWithUsernameDto
예)
PostWithContentDto
- id
- 날짜
- 제목
- 내용
MemberWithUsernameDto
- id
- 날짜
- 권한
- username
❗ 절대 넣으면 안 되는 것
👉 “내 정보 조회”처럼 필요한 상황이 아니면 절대 포함하지 않는다.
PostWriteReqBody
PostModifyReqBody
PostCommentWriteReqBody
PostCommentModifyReqBody
record PostWriteReqBody(
@NotBlank
@Size(min = 2, max = 100)
String title,
@NotBlank
@Size(min = 2, max = 5000)
String content
) {}
✔ JSON으로 입력받는다면 반드시 만든다
✔ 검증(@Valid)을 위한 최소 단위
PostWriteResBody
PostModifyResBody
PostCommentWriteResBody
PostCommentModifyResBody
record PostWriteResBody(
long totalCount,
PostDto post
) {}
❗ 무조건 만들 필요는 없다
이 강의에서 가장 좋았던 점은
“무조건 이렇게 해라”가 아니라,
어디까지가 적절한 선인지
언제는 단순하게 가도 되는지
그 기준을 명확히 잡아줬다는 점이다.
앞으로 DTO를 만들 때
이 판단을 훨씬 수월하게 할 수 있을 것 같다.