search

woowacourse / tecoble-comments

0 stars 0 forks source link

post/2021-04-25-dto-layer-scope/ #56

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

DTO의 사용 범위에 대하여

  1. DTO란? DTO(Data Transfer Object)란 계층간 데이터 교환을 위해 사용하는 객체(Java Beans)입니다. 간략하게 DTO의 구체적인 용례 및 필요성을 MVC 패턴을 통해 알아볼까요? 🚀 1.1. MVC 패턴 MVC…

https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/?utterances=3c6ab8434aa798d9893d82c3oKK6F87brylLSlOKmTcFGjAZDWYNxlZBTSZjhTM4rjRGrC5FLYTxNojQMNG6cVkJZa061FjcYX%2BARO1NSZRi%2B1k0tCgRhyWFx219My8a%2BjQKpho8apbBOF3MoUo%3D

sb33333 commented 2 years ago

안녕하세요? 스프링에 대해 검색하다 글을 읽게 되었습니다. 좋은 글 잘 읽었습니다. 감사합니다~!

leo0842 commented 2 years ago

글에 정성이 묻어나오는 것 같습니다. DTO 의 변환 시점에 대한 궁금증이 있었는데 시원하게 풀렸습니다. 감사합니다!!

basepage90 commented 2 years ago

좋은 글 잘 읽었습니다. 덕분에 DTO 와 VO 사용범위에 대해서 생각정리가 되었습니다. Service 에서 Repository 로 넘길때, 파라미터가 너무 많은 경우 DTO 통째로 넘기는 경우가 있었는데.... Service 단에서 한번 더 처리를 해주는게 좋을 것 같네요.

그리고 저도 Entity 가 DTO 로 반환되는 계층은 Service 가 적합하다고 생각합니다. Controller api Resolver 계층은 최소한의 코드... 즉 비즈니스로직이 머물면 좋지않다고 생각합니다.

basepage90 commented 2 years ago

아... 어제까지는 라고 생각했었는데요. QueryDsl 을 사용한다면, @QueryProjection 을 사용하게 될것이고, DTO 가 repository 단에서부터 생성 되어 나가게 되죠. 이 방식이 싫다면, Entity 에서 @Transient 로 Projections.fileds 를 사용해야 할 거고요. 이건 또 이거대로 문제가 생기기도 하죠. 어떤 방식이든 예외 상황을 모두 커버 하는데는 한계가있는 것 같아요. 상황에 맞는 유연함을 보여야 하는게 아닌가 싶어요.

underdarks commented 2 years ago

제 개인적인 경험으로 Service단에서 Dto -> Entity , Entity -> Dto로 변환할때 추후 코드에 대한 변경이 있을때 해당 .java파일만 수정해서 고치면되서 유지보수 하기가 되게 편했던거 같네요

leechunghyun95 commented 2 years ago

안녕하세요. 글을 읽다가 궁금한것이 생겨 질문드립니다. UserDto.java와 UserController.java 예시 코드 쪽에서 보면 UserDto의 생성자를 선언하므로써 return ResponseEntity.ok().body(new UserDto(user)); 이런 형태로도 반환 가능한데 from이라는 함수를 따로 사용하신 의미는 무엇일까요?

hoonkii commented 2 years ago

좋은 글 감사합니다! 저는 장고를 쓰지만 이 부분이 항상 고민인 것 같아요. 헥사고날 아키텍처처럼 서비스 레이어가 API 웹 컨트롤러 에서만 사용되는 것이 아니라, 다른 곳에서도 사용 된다면 서비스에서 DTO로 변환해서 전달하기보다 각 파트에서 서비스의 파라미터를 DTO 로 변경해야하지 않을까..? 라는 생각이 들었네요. 정답은 없는 것 같습니다.

young0264 commented 1 year ago

정말 맛있게 잘 읽었습니다! 패키지 구조를 어떻게 가져가야 하는지 또 dto의 활동범위를 어디까지 허용해 줘야 하는건지 항상 고민인데요. 저도 controller에서의 책임은 줄이고 service에서 dto에 관련된 작업을 하는게 맞다 생각합니다. 왜냐하면 controller단에서 dto에 관련된 변환등의 작업을 하기 시작하면(그 순간 개발자는 편한데..) 토이프로젝트라도 어느정도 진행되고 나면 service하고 controller의 역할이 애매해지더라구요.. 하나의 역할을 두명이 하고 있는걸 보고 항상 고민이 많던 찰나 이 글을 또 보게되네요 ㅎㅎ 많이 배우고 갑니다!

binary-ho commented 1 year ago

좋은 글 감사합니다

stir084 commented 2 months ago

생각을 해봤는데 결론은 역시 아인슈타인입니다. 헥사고날에 입각해서 도메인을 리턴하면 뭐 어거지로 만들수야 있겠지만 프로그램의 복잡성이 올라갑니다. 시스템의 분리 측면에서는 성공적이겠지만요. 그래서 이건 단순하지 않습니다. 역시 계층형 아키텍처로 서비스에서 DTO를 반환하는 것이 가장 이상적인 것 같습니다. 재사용성이 떨어진다 이런 얘기도 있지만 그건 코드를 얼마나 잘 짜느냐에 따라 달린거지. 시스템을 강제로 분리 시키는 헥사고날이어도 코드를 충분히 엉망으로 짤 수 있기 때문입니다. 잘 짜여진 계층형 아키텍처는 언제든지 시스템 분리도 가능할 거라고 예상합니다.