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

DTO 디렉토리 구조 변경 #166

Merged
merged 21 commits into from
Dec 6, 2023
Merged

DTO 디렉토리 구조 변경 #166

merged 21 commits into from
Dec 6, 2023

Conversation

EunhoKang
Copy link
Collaborator

진행 내용

  • dto를 API 요청별로 분류

스크린샷 (선택)

image

@EunhoKang EunhoKang added the enhancement 개선 label Dec 5, 2023
@EunhoKang EunhoKang self-assigned this Dec 5, 2023
@github-actions github-actions bot added the android 안드로이드 관련 label Dec 5, 2023
Copy link
Collaborator

@ootr47 ootr47 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@Taewan-P Taewan-P left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

폴더로 나눈건 정말 좋은 것 같습니다.

추가적으로 고려해보면 좋을 것 같은게 있는데,

  • 파일 이름에 DTO가 붙은것과 안붙은것의 차이는 무엇인가? (DTO는 계층간 데이터 이동용? 계층 이동할때만 쓰이는가?)
  • 한 파일에 여러 클래스가 들어있는것과 하나만 들어있는것이 섞여있는데 이유가 있는가?

이 부분에 대해서 이야기를 나눠보면 좋을 것 같습니다.

@EunhoKang
Copy link
Collaborator Author

폴더로 나눈건 정말 좋은 것 같습니다.

추가적으로 고려해보면 좋을 것 같은게 있는데,

  • 파일 이름에 DTO가 붙은것과 안붙은것의 차이는 무엇인가? (DTO는 계층간 데이터 이동용? 계층 이동할때만 쓰이는가?)
  • 한 파일에 여러 클래스가 들어있는것과 하나만 들어있는것이 섞여있는데 이유가 있는가?

이 부분에 대해서 이야기를 나눠보면 좋을 것 같습니다.

각 질문에 대해 제 대답을 적자면,

  • DTO는 서버에서 전송되는 데이터를 처리하기 위해 만들어진 객체입니다. 응답 자체는 Response로 역직렬화되어 수신하며, Response 내부에서 추가적으로 객체로 표현되는 데이터가 있을 경우 DTO를 붙입니다.
  • 현재 내부에 여러 파일이 존재하는 경우는 UI에서 사용되는 데이터 클래스가 같이 존재하는 경우입니다. 이에 대해서 어떻게 하는 것이 좋아보이시나요?

@Taewan-P
Copy link
Member

Taewan-P commented Dec 5, 2023

서버에서 전송되는 데이터를 처리하기 위해 만들어진 객체는 **Response쪽 객체 아닌가요?
그리고 Response 내부에서 추가적으로 객체로 표현되는 데이터에는 **Result가 붙어 있는 것 같습니다. (이 또한 지금 통일되어있지 않음) (그때 Result로 한 이유는 API에서 오는 데이터 중 ViewModel 입장에서 필요없는 데이터는 없애고 전달하기 위함이었음)

image

@EunhoKang
Copy link
Collaborator Author

서버에서 전송되는 데이터를 처리하기 위해 만들어진 객체는 **Response쪽 객체 아닌가요? 그리고 Response 내부에서 추가적으로 객체로 표현되는 데이터에는 **Result가 붙어 있는 것 같습니다. (이 또한 지금 통일되어있지 않음) (그때 Result로 한 이유는 API에서 오는 데이터 중 ViewModel 입장에서 필요없는 데이터는 없애고 전달하기 위함이었음)

image

아, 말을 잘못 적었네요. DTO는 서버에서 요청으로 보내거나 응답으로 받는 데이터입니다.
Result 관련해서는 상기하신 이유가 아니더라도 UI에서 사용되는 데이터 타입이 데이터 통신에도 사용되는 것은 바람직하지 않아 분리했던 것으로 기억합니다.

아무튼, 해당하는 파일들의 데이터 타입 분리가 필요하다고 생각하시나요? 필요하다면 어떻게 분리하는게 좋을까요?
저는 분리가 필요하다면 Result 등 UI에서 사용되는 데이터 클래스들은 원래 ui에서 쓰려고 만든 클래스들이기 때문에 ui.data로 옮기는 방식으로 정리할 것 같습니다.

@Taewan-P
Copy link
Member

Taewan-P commented Dec 5, 2023

지금 ProductVerifyDTOUserDataDTO 를 제외하고 나머지 DTO로 명명된 클래스들은 모두 data 영역 내에서만 사용이 됩니다.

DTO는 서버에서 요청으로 보내거나 응답으로 받는 데이터입니다.

말씀대로라면 이들 두 그룹 중 하나는 이름 변경이 필요해 보입니다.

파일들의 데이터 타입 분리가 필요하다고 생각하시나요?

저는 일단 다른 파일들은 다 분리가 되었으니 마찬가지로 분리가 되어야한다고 생각합니다. 하지만 UI에서 쓰려고 만든 클래스긴 하지만 결과적으로 Data Layer에서 전달해주는 데이터 타입이기 때문에 ui 패키지 하위로 옮기는게 옳은지는 모르겠습니다.

@EunhoKang
Copy link
Collaborator Author

그렇다면 ProductVerifyDTOUserDataDTO가 사용되는 부분은 이름을 바꾸거나 다른 클래스로 대체해야 할 것 같네요.
이 부분은 작업해서 커밋하겠습니다.

파일 분리는 하는 것이 좋아보이고, ui.data가 별로라면 data.ui에 두는 것은 어떠신가요?
패키지 구조가 크게 꼬이지 않으면서 해당 데이터가 ui에서 쓰인다는 의미를 전달할 수 있을 것 같아 제안드립니다.

@Taewan-P
Copy link
Member

Taewan-P commented Dec 5, 2023

Repository도 data영역으로 포함되니 ProductVerifyDTO는 확실히 변경이 필요해 보이네요.

data.ui폴더 보다는 이전에 말씀하신 ui.data가 더 의미적으로 맞는 것 같습니다. 죄송합니다 😅

@EunhoKang
Copy link
Collaborator Author

EunhoKang commented Dec 5, 2023

Repository도 data영역으로 포함되니 ProductVerifyDTO는 확실히 변경이 필요해 보이네요.

data.ui폴더 보다는 이전에 말씀하신 ui.data가 더 의미적으로 맞는 것 같습니다. 죄송합니다 😅

넵, 알겠습니다. 오늘 중으로 추가 커밋 보낸 후 다시 리뷰 요청 드리겠습니다!

Copy link
Member

@Taewan-P Taewan-P left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

수고하셨습니다!

Copy link
Collaborator

@ootr47 ootr47 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

확실히 개선이 많이 된 것 같네요😄 어려운 부분들 혼자서 리팩토링하시느라 고생하셨습니다!

@ootr47 ootr47 merged commit e928bbb into dev/and Dec 6, 2023
2 checks passed
@EunhoKang EunhoKang deleted the refactor/and/dto branch December 6, 2023 02:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
android 안드로이드 관련 enhancement 개선
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants