Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feat] DTO Naming convention #4

Open
johan1103 opened this issue Nov 2, 2023 · 1 comment
Open

[Feat] DTO Naming convention #4

johan1103 opened this issue Nov 2, 2023 · 1 comment
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@johan1103
Copy link
Contributor

DTO 이름을 어떻게 지어야 할까요? 🤔

현재 상황…

맛집 정보를 DB에서 쿼리로 가져온 이후에,

해당 정보를

  1. Repository 계층의 RestaurantRepository에서 RestaurantService
  2. Service 계층의 RestaurantService에서 RestaurantController
  3. 가져와 Dto를 RsData내부에 넣어서 응답해주려고 합니다.

일단 제 개인적인 생각으로는 전제조건이 RestaurantService의 Return값, RestaurantRepository의 Return값이 전부 다른 Dto여야 한다고 생각합니다.

RestaurantRepository로부터 가져온 DB와 직접적 연관을 가지는 객체와, RestaurantService가 응답하는 객체는 객체의 존재이유가 완전히 다르다고 생각해서입니다.

둘의 존재 이유는 각각

  • Repository계층에서 반환해주는 객체는 DB로부터 단건으로 가져올 수 있는 정보
  • Service계층에서 반환해주는 객체는 Controller에서 요구하는 최종적인 가공이 된 정보

라고 생각합니다.

Service 계층에서 어쩔 수 없이 DB에 여러번 요청을 해서 응답 데이터를 가공해야 하는 상황이라면 Service Layer에서 응답하는 객체와 Repository Layer에서 응답하는 객체가 달라질 수 밖에 없는 상황이 생길 것이라고 생각해요.

모든 계층에서 생성되는 DTO이름을 어떻게 정할 지 고민입니다…..

정리하자면 다음과 같은 고민이 될 것 같습니다.

  1. 딱 네이밍만 봤을 때,

    “Repository 계층에서 사용하는 클래스네! 아님 Service 계층에서 사용하는 클래스네!” 라고 알 만한 네이밍 방법이 있을까요?

  2. 너무 여러개의 객체가 생성됩니다.

    3개의 URL 엔드포인트가 있고, Controller → Service → Respository 계층을 거친다고 가정하면, POST로 Request용 Dto를 생성하지 않는다고 가정해도

    총 9개(3*3)의 Dto가 만들어집니다.

    DTO 패키지를 만든다고 해도 너무 많은 양 같아요.

찾아본 결과

DTO를 Inner Class 형태로 넣는 방법이 있는것 같습니다.

DTO 는 어떻게 구성하고, 변환해야 할까?

Spring Boot에서 깔끔하게 DTO 관리하기

DTO간의 매핑 방법은 이런게 있는것 같아요

The DTO Pattern (Data Transfer Object) | Baeldung

@johan1103
Copy link
Contributor Author

팀 노션에도 게시했습니다!
노션링크

@CheorHyeon CheorHyeon added the documentation Improvements or additions to documentation label Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants