Service 메서드 파라미터에 대한 DTO 적용 여부 논의

[Jake1152]

service 구현 중 파라미터 수가 5개 이상인 경우가 발생하였습니다.
너무 많다는 생각 들어 DTO를 써볼까 생각해보니 쓸거면 다른 service 메서드들에서도 일관적으로 적용하는게 낫지 않을까 생각듭니다.
Service 메서드 파라미터에 대한 DTO 적용에 대해 어떻게 생각하시나요?

참고자료

• 인프런 | controller, service용 dto를 분리시키는 것에 대한 질문

[jihwan1211]

저는 dto가 data transfer object라고 나와 있길래 네트워크에서 주고 받는 데이터의 형태를 정의한다고만 생각했는데
인프런 질의 응답보니 마냥 그렇게만 부르는 거 같진 않네요.

그럼 저도 궁금한게 단순히 movie를 찾는 서비스를 만든다고 하면,
해당 서비스의 응답 DTO를 따로 정의해줘야하나요?
아님 응답 값이 movie 엔티티랑 동일하니까 그냥 movie 엔티티로 응답 타입 명시해줘도 되나요?

[jihwan1211]

저는 dto가 data transfer object라고 나와 있길래 네트워크에서 주고 받는 데이터의 형태를 정의한다고만 생각했는데 인프런 질의 응답보니 마냥 그렇게만 부르는 거 같진 않네요.

그럼 저도 궁금한게 단순히 movie를 찾는 서비스를 만든다고 하면, 해당 서비스의 응답 DTO를 따로 정의해줘야하나요? 아님 응답 값이 movie 엔티티랑 동일하니까 그냥 movie 엔티티로 응답 타입 명시해줘도 되나요?

자문자답입니다 dto 만들어주는게 좋다고 하네요

[Jake1152]

저는 dto가 data transfer object라고 나와 있길래 네트워크에서 주고 받는 데이터의 형태를 정의한다고만 생각했는데 인프런 질의 응답보니 마냥 그렇게만 부르는 거 같진 않네요.
그럼 저도 궁금한게 단순히 movie를 찾는 서비스를 만든다고 하면, 해당 서비스의 응답 DTO를 따로 정의해줘야하나요? 아님 응답 값이 movie 엔티티랑 동일하니까 그냥 movie 엔티티로 응답 타입 명시해줘도 되나요?

자문자답입니다 dto 만들어주는게 좋다고 하네요

제가 지금 만드는 api에서는 service, controller response DTO가 같게 되더라고요

service에 있는 파라미터에 대한 DTO 적용은 어떻게 생각하시나요?
다른 곳에서도 service provider를 가져다 쓴다면 파리미터에서도 DTO 확인하는 게
좀 더 안전한 프로그래밍 될 수 있지 않을까 싶습니다

[jihwan1211]

https://docs.nestjs.com/techniques/validation#mapped-types
이런 상황은 이렇게 하면 될 것 같은데

https://docs.nestjs.com/providers#services
여기 보면 또 그냥 interface로 정의하기도 하네요

request로 데이터 받을 때만 class 사용하고
아니면 그냥 interface 사용하네요

[Jake1152]

저는 dto가 data transfer object라고 나와 있길래 네트워크에서 주고 받는 데이터의 형태를 정의한다고만 생각했는데 인프런 질의 응답보니 마냥 그렇게만 부르는 거 같진 않네요.
그럼 저도 궁금한게 단순히 movie를 찾는 서비스를 만든다고 하면, 해당 서비스의 응답 DTO를 따로 정의해줘야하나요? 아님 응답 값이 movie 엔티티랑 동일하니까 그냥 movie 엔티티로 응답 타입 명시해줘도 되나요?

자문자답입니다 dto 만들어주는게 좋다고 하네요

제가 지금 만드는 api에서는 service, controller response DTO가 같게 되더라고요
service에 있는 파라미터에 대한 DTO 적용은 어떻게 생각하시나요? 다른 곳에서도 service provider를 가져다 쓴다면 파리미터에서도 DTO 확인하는 게 좀 더 안전한 프로그래밍 될 수 있지 않을까 싶습니다

Reason for using DTO and Interface in NestJS Basically, in rest API, we have two types of operation, One is Input and Another is Output. which is Request and Response

During response, we don't need to validate the return value. We just need to pass data based on the interface

But in request, we need to validate the body

for example, you want to create a user. Then the request body might be something like this

const body = { name: "Test Name", email: "[email protected]", phone: "0393939", age: 25 } so during request we need to validate email, phone number or password is matched regex etc.

so in DTO we can do all validation

Here is one of my DTO example import { IsEmail, IsNotEmpty, IsString, MinLength } from 'class-validator';

export class RegisterUserRequest { @IsString() @isnotempty() name: string;

@isemail() @isnotempty() email: string;

@isnotempty() @minlength(6) password: string; }

export class LoginUserRequest { @isemail() @isnotempty() email: string;

@isnotempty() @minlength(6) password: string; } And here is the interface example import { UserRole } from './user.schema';

export interface UserType { _id?: string; email?: string; name?: string; role: UserRole; createdAt?: Date; updatedAt?: Date; }

Hope you understand.

Body, Param 등만 class 나머진 interface인 거 같습니다

아하 밖에서 데이터를 받는 controller에서는 request 받을 때의 검증을 위해 class를 DTO로 쓰고 그 외에는 서버 내부에서 처리한 데이터들이니까 검증할 필요는 없어서 interface이면 되나보네요
고맙습니다:)

[jihwan1211]

근데 조금 더 찾아보겠습니다 사람마다 의견이 다르네요

[Jake1152]

저도 좀 더 찾아봐야겠네요 고맙습니다ㅎ

[jihwan1211]

찾아보니까 매개변수가 많으면 dto 다들 사용하시는 것 같습니다만,
한 곳에 dto 적용했다고 매개변수 1개 2개인 함수도 dto를 따로 만드는 것 같진 않습니다.

또 class랑 interface는 뭐가 정답이다는 없는 것 같습니다.
그래서 그냥 공식문서 예제 따라는게 좋을 것 같다는 생각입니다.