DTO >.<
오늘은 팀원인 Tree와 함께 DTO에 관한 이야기한 것을 정리하고 싶다.
이번 프로젝트를 진행하면서 Tree가 제안한 DTO설계는 이런식이다.
// Entity
- Game
- Player
// DTO
- GameListResponseDTO
- GameScoreResponseDTO
- PlayerResponseDTO
- PlayerDetailResponseDTO
내가 이전 프로젝트에서 DTO를 학습하고 적용시켰던 DTO의 형태는 아래와 같다.
// Entity
- Game
- Player
// DTO
- GameDTO
- PlayerDTO
둘의 차이점은?
Tree가 제안한 건 Entity에서 어떤 특정기능과 요청/응답을 분리하여 필요한 필드만 뽑아서 DTO로 만든 것이다.
예를 들면, GameListResponseDTO는 Game을 List로 가지는 속성을 가지기 위해 Game 자체를 속성으로 가져온다. GameScoreResponseDTO는 Game 내에 스코어를 속성으로 가진다.
굉장히 독립적인 DTO라고 할수 있을것 같다.
내가 만든건 Entity의 필드들을 그대로 가져오지만 응답해줄 때, 필요한 데이터 타입에 따라서 변화를 주기위해서 만든 DTO였다.
예를 들면, Entity 내에 가격이라는 속성이 있는데 디비에서 5900 이라고 저장했다고 치자.
근데 응답해줄 때는 5,900원 이라고 응답해주고 싶다면 어떻게 할건가?
Entity를 다시 공사하나? ㄴㄴ DTO를 사용하는거다.
이런식으로 데이터 타입에 변화를 주려는 목적에서 DTO를 만들었다.
뭐가 좋은가?
Tree가 제안한 걸 사용하면 생각나는 좋은점은 아래와 같다
-
응답할때 어떤 DTO를 사용해야할지 명확해지므로 필요한 속성(컬럼)에만 집중할 수 있다.
-
Entity와 독립적이다. 일단 왜 독립적이라고 생각하냐면, 제한된 속성만 나열되어있기 때문에 사용의도가 명확하다. 그렇기때문에 Entity를 받아서 DTO로 데이터로 변환하는 메서드 외에는 서로 교류할 일이 거의(?) 없다고 생각해서 독립적이라고 생각한다.
그러면 독립적인게 왜 좋은건가? 서로의 계층이 정확하게 분리되기 때문이다. 코드가 많아지면 많아질수록 서로가 독립적으로 움직이는 것이 크게 도움될 것이다. -
가독성이 좋아진다? 왜냐? 네이밍에서부터 사용목적을 드러내기 때문에, 서비스단이나 컨트롤러단에서 이 DTO를 볼때 좀더 그 메서드의 사용의도가 명확해진다.
내껄 사용하면 좋은점은?
- 그냥 간단하다. Entity에 대한 DTO가 하나이기 때문이다. 이거 하나로 다 처리해주면 된다.
적다보니 Tree가 제안한게 내가 사용하던 방법보다 더 진보된 방법일까라는 생각이 든다.
참고해볼만한
깃 배운거
git reflog
jps
이슈/위키 관리
코딩 시작하기전 해야할 거 이슈 생성
코딩 하면서 문제 생기면 바로 이슈 생성
이슈/PR 번호로 위키에 문제해결 업로드 (나만의생각)
