DTO vs 파라미터 전달

Question

안녕하세요.기술 관련해서 질문 드리고 싶습니다.Controller에서 값을 받아 Service > Repository로 데이터를 넘기는 과정 중 컨벤션을 정하고 있는데 의견 대립이 있어, 다수의 의견으로 진행하고자 글 남깁니다!상황 설명을 드리자면,자바 스프링 사용개발이 꽤 진행된 상황이며, 파라미터가 4개 이상인 메서드도 다수 존재할 예정. 현재 1~2개 파라미터가 상당 수 차지.의견 1Controller에서 Service나 Repository로 값을 전달할 때, Request 값을 개별 파라미터로 직접 전달하는 것이 좋다.즉, getBoard(Long boardId, Long memberId, ...)처럼 DTO 없이 파라미터를 직접 넘기는 방식이 개발 속도를 높일 수 있다.만약 Controller의 Request 값이 변경된다면, 이는 비즈니스 UseCase 자체가 변경된 것이므로, 다른 레이어(Service, Repository)도 변경되는 것이 자연스럽다. 따라서, Request 값 변경에 따라 다른 레이어의 변경이 발생하는 것은 문제되지 않는다.의견 2DTO를 만드는 과정이 다소 번거로울 수 있지만, 전달해야 할 파라미터 개수가 많아질수록 실수할 가능성이 커진다. 따라서, Controller에서 받은 Request 값을 Command DTO로 매핑하여 Service, Repository로 전달하는 방식이 더욱 안정적이다.만약 Controller의 Request 값이 변경되거나 줄어든다면, Service와 Repository의 메서드도 함께 수정해야 한다. 그러나 레이어드 아키텍처에서 하위 레이어(Service, Repository)의 변경이 상위 레이어(Controller)에 영향을 주면 안 되므로, 각 레이어에 종속된 DTO를 활용하여 변경의 영향을 최소화하는 것이 바람직하다.이에 따라, 파라미터 개수가 1~2개라면 그대로 전달하고, 3개 이상이면 Command DTO를 만들어서 넘기는 방식이 적절하다.위 의견이 대립중입니다어떤 게 맞는 정답일까요??정보가 부족하다면 질문주시면 성실하게 답변드리겠습니다.감사합니다:)

wharup · Answer

Controller에서 바로 요청 DTO를 받아서 Service로 넘기는 형태로 사용중인데요REST API에 문서를 자세히 달아야하는 시스템이라 선택한 케이스입니다.주고 받는 파라메터가 많은데 Controller 메소드 별 파라메터에 하나하나 달기에는 양이 많아져서 각 요청별로 DTO에 담는 식입니다.부수적으로 좋은건 요청에 대한 작은 판정 로직등을 DTO에 담기조 좋더라고요.

제육국밥돈까스 · Answer

map<string, object>

캐티 · Answer

이거 함 바바여 c#에 설명이 좋스빈다. 이렇다 하더라도 만능이라 생각하지 않아요.DTO(데이터 전송 개체) 만들기 | Microsoft Learn이케 구조화된 데이터에 장점이라 함은 json으로 직렬화 하거나 역직력화 하거나 이럼 좋겟쩌.C#에서 JSON을 직렬화하는 방법 - .NET | Microsoft Learn경우에 따라서 전달 방법이 달라지는 수가 있어요. 함수에 불필요하게 데이터 셋트를 전달할 이유가 없지 않나요. signout 같은 경우에는 아이디 내지는 세션만 인자로 전달하면 댈거여요.

하루히즘 · Answer

저도 2번에 한표.. 필드 10개를 받는 검색조건 중 2개는 입력해야 한다 같은 조건을 넣을 때 dto 안에 그런 로직을 묶을수도 있고 그렇더라구요

장독깨기 · Answer

정답 없습니다. 정답 찾으려 고민하지 마시구요,기본적으로 CRUD 가 있습니다.RD 는 의견1로, CU 는 의견2로 한 번 검토해보세요.

カワウソ · Answer

squid:S107 과 비슷한 관점이죠 뭐.

개발잡부 · Answer

혼자 개발할땐 모르겠는데같이 개발할땐 무조건 2번입니다.Map으로 관리하면 코드만 보고서는 도대체 어떤 Request와 Response가 오고가는지 알수가 없습니다;그렇다고 API 문서가 항상 정확하던가요?가장 정확한건 코드이고, 코드로 이해할수 있어야하고코드로 히스토리 관리가 되어야 합니다.

월급은나의빛 · Answer

필드 추가될 때마다 인터페이스 바꾸는 걸 반복하다 보면, 2번으로 기울게 될 겁니다. 인터페이스로 노출되지 않는 게 미덕인 경우도 많고, 그걸 encapsulation이라고 부르는 것 아닐까 하는 생각이네요.

임시저장보관소 · Answer

흠... 꽤 위험한 생각이 숨어있네요즉, getBoard(Long boardId, Long memberId, ...)처럼 DTO 없이 파라미터를 직접 넘기는 방식이 개발 속도를 높일 수 있다.여기서 둘다 long 인데 실수로 섞어보세요...getBoard( member.id, board.id,)아니 실수 아니어도 git merge 과정에서 섞이면...

ykd · Answer

dto 라 부르는 것은 의미를 부여하는 과정이라 생각합니다.예를들어 목록 조회에 쓰이는 파라미터로size, order, page, filter, keyword 라는 파라미터가 있을 때각각을 RequestParam으로 처리할 수도 있겠지만 ListSearchRequestParams같은 객체로 래핑하여 전달함으로써 다수의 파라미터 용도를 명확히 할 수 있습니다.또한 이를 business logic layer, persistence layer까지 전달할 때도 인자를 줄일 수 있는데요. 클린코드 가이드상으로도 이러한 방향이 옳지 않나 합니다.성능오버헤드라 할만한게 있을 지 모르겠다만 현대 컴퓨팅 환경에서는 체감조차 못할 미미한 수준으로 예상됩니다

집킨 · Answer

참고로 진정한 객체지향 프로그래밍은 Long boardId 가 아니라 BoardID boardId 이런식으로 기본타입도 래핑해서 의미있게 써야합니다물론 이렇게 해야만 한다는건 아니고, 이런것까지 생각해보면 매개변수 둘 이상일때 DTO선택은 꽤나 합리적이라는 뜻이죠

짱구올시다 · Answer

파라미터가 많다면 DTO, 적다면 파라미터. 전 이렇게 갑니다.

마늘냄새폴폴 · Answer

저도 2번이 취향입니다. 1번도 종종 쓰는데 메서드에서 그 의미가 정확히 판단되는 경우에 사용해요. 예를 들어서changeName(beforeName, afterName);이런식으로 사용할 땐 DTO로 하는 것 보다 그냥 매개변수로 넘겨주는게 코드 가독성이 좋아져서 이렇게 사용합니다. 무조건 1번 2번 중 하나를 선택해야한다면 2번이 더 취향입니다.

초무쿤 · Answer

딱히 정답이 있는 문제는 아닐텐데용..저같은 경우는GET의 경우는 1번 Parameter (기껏해봐야 검색조건인데 몇개나 추가될런지.)POST 등 payload가 있는 경우 2번 DTO근데..이런 디테일까지 합의를 보고 하기는 힘들껄요..(은탄환은 없다. 모든걸 Parameter로 할수도 없고 DTO로 할수도 없고.)절대적인 기준(절대 하면 안되는것만 정의)만 정하고 나머지는 재량껏 가는게 맞을지도요..이런 논의까지 할 정도면 다들 개발바닥에서 좀 뒹구신 분들일텐데..이런거로 논쟁하면 서로 감정 상해서 오히려 프로젝트 리스크만 커질지도..

제레미codes · Answer

2번 좋습니다표준적인 방법은 애플리케이션의 각 계층 간에 계약을 생성하는 것입니다. 이는 개발자들이 컨트롤러 수준에서 클라이언트와 서버 간에 계약을 맺는 방식과 유사합니다. 계약이 유지되는 한, 구현은 소비자에 영향을 주지 않고 쉽게 수정될 수 있습니다.일부 팀은 "쿼리"(GET)와 "명령"(POST, DELETE, PATCH 등)에 대해 별도의 클래스를 생성하는 수준까지 나아갑니다. 예를 들어, CreateUserCommand, DeleteUserCommand, GetUserQuery를 가질 수 있습니다. 이 패턴에 대해서는 자세히 설명하기 어렵기 때문에 못 하는데 관심이 있으시다면 CQRS를 찾아보세요. 하지만 간단한 이점은 일관된 명명 규칙입니다. 서비스 계층에서 이러한 명령과 쿼리를 받아 "계약" 역할을 하게 하세요. 이제 요청에 변경 사항이 생기면 애플리케이션의 여러 계층 대신 명령이나 쿼리만 업데이트하시면 됩니다. 성능에 미치는 영향은 꽤 작아서 없는 걸로 보시면 됩니다.

개발 까마귀 · Answer

https://github.com/tipjs/javascript-style-guide자바 계열의 컨벤션 스타일 가이드는 아니지만 여기서 파라미터가 3개이상이면 Object로 받는다로 되어있습니다. 여기서 말한거처럼 파라미터가 늘어나면 그 순서를 기억해야하므로 힘들고 유지보수가 힘들어진다는것이죠 따라서 저도 2번에다가 파라미터가 2개이하면 그냥 넘기고 3개이상이면 DTO로하는거를 추천드립니다.

DTO vs 파라미터 전달

16개의 답변

#dto 목록