[Backend] Join Table의 DTO 변수 이름 작성

[dnjsals45]

DTO를 만들다보니, 한 DTO에 여러 개의 Table 데이터가 들어가야 하는 경우가 있습니다.

이러한 정보들을 주입할 때 현재 저는

이렇게 Table명 + Column 명으로 작성을 하고 있었는데, 다른 분들의 작성법과 통일을 하면 좋을 것이라고 생각해서 discussion 남겨봅니다.

[rkskekzzz]

아래와 같은 방법은 어떠신가요???
java를 잘 몰라서 js로 작성했습니다 ㅜㅜ

{
  content: {
    id: number
    title: string
    body: string
    type: string
  },
  user: {
    name: string
    profileImageUrl: string
  },
  category: {
    categoryId: number
    color: string
    name: string
  }
}

[ChanHoHan]

엔티티 클레스랑 완전히 동일한 DTO를 만들고, 그 DTO들을 묶은 클레스를 만든다면, 이렇게도 가능할거 같네요 ~

[psychology50]

근데 이렇게 하면 직렬화할 때 엄청 꼬이지 않던가요? 뭔가 전에 고생했었던 잠재된 기억이....ㅋㅋㅋㅋㅋㅋ

[ChanHoHan]

앗 저거는 entity 인스턴스를 단순히 converting한 후에, service단에서 쓰이는 DTO 말씀하신거 같아서 말씀드렸습니다 ㅎㅎ

[rkskekzzz]

타입스크립트를 사용하는 입장에서 보면, 이렇게 나눠서 사용할때 장점이 있을 것 같습니다!
아래처럼 기본 Content 타입을 만들고 Response시에 Pick 등을 활용해서 타입을 좁힐 수 있을 것 같습니다.

type Content = {
  id: number
  title: string
  body: string
  type: string
  updatedAt: string
  createdAt: string
  deletedAt: string
}

type User = {
  id: number
  name: string
  email: string
  profileImageUrl: string
  createdAt: string
  updatedAt: string
  deletedAt: string
}

type Category = {
  id: number
  name: string
  createdAt: string
  updatedAt: string
  deletedAt: string
}

type ContentResponseDTO = {
  content: Pick<Content, 'id' | 'title' | 'body' | 'type'>
  user: Pick<User, 'name'| 'createdAt'>
  category: Pick<Category, 'name'>
}

기존 방식으로도 구현이 가능하긴한데 지금 해보고 있는데 Value 타입을 정의하기가 쉽지 않네요..

type PickContent = Pick<Content, 'id' | 'title' | 'body' | 'type'>
type ContentResponseDTO = {
  [key in `content${Capitalize<keyof PickContent>}`]: Value
}

[ChanHoHan]

변수명은 저는 정하기 나름이라 생각해서, 저런 케이스에는 테이블명 + 컬럼명 좋은 것 같습니다.

[psychology50]

들어가는 모든 도메인 명을 붙여서 DTO를 짓기엔 좀 무리가 있고, DTO가 사용되는 목적에 따라 네이밍을 하면 좋을 것 같은데 명확한 기준이 안 떠오르네요.
이 방법은 다른 사람이 작성한 DTO를 재활용하기 쉽지 않을 것 같긴 하네요

[psychology50]

아, 저는 찬호님 말씀이 특정 Response에 여러 개의 Entity에 대한 DTO가 필요하다고 하면

class WrapperDto {
    private MemberDto member;
    private CategoryDto category;
    ...
}

이런 방식으로 하자고 말씀하신 걸로 이해했어요.

그게 구체적으로 어떤 상황이었는지가 좀 애매한데, DTO 안에 DTO 리스트였나 뭔갈 넣다가 직렬화할 때 제법 애먹었던 것 같아요.
그냥 저 혼자 뻘짓했던 걸 수도 있습니당. ㅋㅋㅋㅋㅋㅋ

[psychology50]

김영한님의 솔루션에 의하면 이런 방법도 있다고 하네요.

[psychology50]

제 개인적인 의견으로는 어떤 상황에서의 Request고 Response인지에 초점을 맞춘 네이밍이어야 할 것 같아요.
내부에 들어가 있는 모든 DTO 종류를 다 붙이면 이름이 너무 난잡해질 것 같고, 어차피 그 또한 재활용성이 높을 거라고 기대하긴 힘들 것 같아서요.

[ChanHoHan]

일단 여담으로, Controller에서 API용으로 사용하는 DTO는, API가 변경될 때 서비스에서 사용하는 코드도 변경될 수 있기 때문에 따로 분리하는게 맞는거 같구요. 그 DTO는 API마다 별개로 만들어야 할거같아요

음 Service에서 사용하는 DTO는 고민을 좀 해바야겠네요 .. 재활용할수 있는 방법 ..

[psychology50]

방법이 있긴 하죠. 각자 생성한 DTO에 대한 문서화를 진짜 기가막히게 작성해둔다면야.....ㅎ