인프런 커뮤니티 질문&답변
작성한 질문수
DTO vs Class
작성
·
589
3
안녕하세요! 강사님
제가 NestJS+ 타입스크립트를 공부를 하면서 헷갈렸던 부분 질 문 드립니다.
DTO를 통해서 타입을 지정해주는 것과 Class를 직접 지정해주는 것의 차이는 어떤 점이 있을까요?
CreateDTO에서 필요한 정보만 DTO에 기입을 하는 부분은 이해헀습니다. 다만 UserEntity에 들어있는 모든 정보를 Create.DTO에서도 받는다고 가정했을 때 타입 지정을 User 클래스로 하는 것과 CreateDto로 지정하는 것의 차이를 모르겠습니다.
짐작하는 것은 Entity는 Class-validator의 적용을 받지 않고 Dto는 Class-validator가 가능한 것으로 생각되는 데 이 부분이 맞을까요??
+ 이미 entity 정의를 할 때 타입을 컬럼별로 타입을 지정하는데 왜 Dto를 통해 타입을 한 번 더 검증해야할까요?? Dto에서 새롭게 객체가 정의되는 경우 때문일까요??
질문 요약
1. 타입을 지정할 때 class를 직접 지정하는 것과 Dto를 만들어서 지정하는 것의 차이는 무엇일까요?
2. 이미 entity에서 타입을 지정헀는데 Dto로 type-validation을 하는 이유는 무엇일까요??
답변 1
5
안녕하세요!
애초에 DTO를 사용하는 이유는 타입 유효성 검사 목적도 있지만 데이터를 주고 받을때 규약(설계도) 느낌으로 안전하게 필요한 데이터만 통신하기 위함입니다. 회원가입을 하는 도메인에서 필요한 데이터는 유저 이름, 유저 이메일, 유저 비밀번호가 있을 겁니다. 하지만 요청을 할때 필요없는 데이터를 보낸다던지, 누락된 데이터를 보낸다던지를 체크할 필요가 있습니다. 이때 DTO가 사용됩니다. 통신 데이터 규칙이라고 생각하면 좋을 것 같습니다.
엔터티는 디비와 연결되는 클래스입니다. 만약 회원가입할때, 요청할때 유저이름은 필요가 없는데 디비 상으로는 필요가 있다면 요청에서는 class SignupDTO { email, password } 가 필요하겠죠. 디비에는 필수적으로 필요하니 백엔드 서비스 코드에 랜덤한 유저 이름을 만들어 최종적으로 디비에 저장할때 넣으면 됩니다. 즉, 엔터티가 디비의 규약이라고 한다면, DTO는 통신에 사용되는 규약이라고 할 수 있습니다.
1. DTO도 클래스로 만들어지기 때문에 차이가 없습니다. (타입이 클래스라면 해당 변수는 지정된 클래스의 인스턴스 및 클래스인 것입니다.) 다만 엔터디 전체를 넣게 되면 엔터티의 모든 메서드, 속성들도 필드가 됩니다. 그렇게 되면 통신을 할때 무조건 엔터티의 모든 필드에 대해 요청 및 응답을 해야 합니다. 물론 DTO가 엔터티와 동일하게 작성될 수는 있습니다. 이는 통신할때 규약과 디비의 규약이 같을 경우인 것이죠. 다른 경우도 충분히 많습니다. 예를들어 적의 공격이 들어왔을때 전방에서 하는 일과 후방에서 하는 일이 같은 경우가 있지만 다를 경우도 충분히 있다는 느낌입니다.
2. 이미 엔터티에서 지정한 유효성 검사를 중복해서 하는 것은 비효율적인 것이 분명합니다. 따라서 바로 다음 강의에서 클래스 상속을 사용합니다. 이러한 이유로 DTO를 단순히 타입으로 만드는 것이 아니라 클래스로 만드는 것이죠.