Schema에서 DTO로 상속하는 과정에서 Decorator와 r... - 인프런

안녕하세요, 강의에서는 Cat 클래스에서 정의한 스키마를 이용해 requestDTO, responseDTO 등으로 상속해서 확장하셨습니다.

검색해보니 이때 원래 파일에 있던 Decorator 등의 메타데이터는 그대로 남아있다고 하는데요, Response 상황에서 어차피 Validation이나 API Property 같은 내용을 신경쓰지 않아도 되니까 상속해도 별 문제가 없긴할거고 강의에서도 그 부분은 크게 신경쓰지 않으신것 같습니다.
혹시 현업에서나 개발 과정에서 저렇게 PickType으로 기존 클래스를 재사용하는 과정에서 기존 클래스에 있던 여러 Decorator 들을 초기화하고 다시 세팅하려면 어떻게 해야할까요?
PartialType으로 래핑하는 방법을 사용하면 required 필드는 사라집니다.
상속을 하니까 API 문서에 표시되는 순서가 id가 가장 나중에 표시가 됩니다. 순서를 바꾸는 방법을 찾지못했는데 방법이 있을까요?
그래서 저는 아예 schema 파일에 id까지 넣은 후에 PickType에서 id 까지 가져오는 방법을 사용해봤습니다.

안녕하세요, 인프런 AI 인턴입니다.

NestJS에서 DTO 중에 특정 속성을 재사용하고 싶지만, 기존 클래스에 정의된 Decorator를 초기화하거나 변경해야 할 경우는 꽤나 정교한 작업이 필요할 수 있습니다. 만약, @nestjs/swagger에서 제공하는 @ApiProperty 데코레이터 같은 메타데이터를 갖는 속성을 변경하거나 제외하려면 기본 클래스를 상속받은 새로운 클래스에서 해당 속성을 다시 정의하고 새로운 데코레이터를 적용할 수 있습니다. 예를 들어, 클래스의 속성에 @ApiProperty({ required: false }) 데코레이터를 덮어쓰려면 같은 이름으로 속성을 선언해 준 후 새로운 옵션을 사용하여 데코레이터를 붙일 수 있습니다.
API 문서에 표시되는 속성의 순서를 조정하고 싶을 때, NestJS의 경우 DTO 클래스의 프로퍼티 순서는 기본적으로 코드상에서 정의된 순서대로 문서에 나타납니다. 하지만 직접적인 제어 메커니즘이 따로 제공되지는 않습니다. 코드 기준으로 정렬이 되지 않는 경우, DTO 클래스를 재정의하거나 순서를 지정해주는 별도의 라이브러리 사용을 고려해볼 수 있겠으나, 이는 NestJS의 공식적인 방법은 아닙니다. 때로는 클래스 리팩토링을 통해서 필드의 순서를 조정하거나, DTO를 새로 정의해서 사용하는 방법을 고려해 볼 수 있겠습니다.

PartialType이나 PickType 같은 유틸리티 타입을 사용하는 방법도 있지만, 이들 타입은 기본적으로 기존 클래스의 메타데이터와 속성들을 전달하여 사용되도록 디자인 되어있습니다. 그러므로, 완전히 새로운 속성이나 데코레이터를 적용하려면 직접 클래스를 정의하거나 기존 속성을 오버라이드하는 방식을 사용해야 합니다. Spring Data JPA의 DTO 클래스 정의 방식과 유사하게, 필요한 속성만 명시적으로 정의하는 방법도 좋은 대안이 될 수 있습니다. (참고: Spring Data JPA - Reference Documentation)

추가적으로, 항상 프로젝트의 코드 조직과 아키텍처, 문서화 방식을 고려하여 가장 적합한 방법을 택하는 것이 중요합니다. 필요한 경우 팀 내부에서 논의를 거쳐 체계적인 협의를 통해 결정하는 것도 하나의 방법이 될 수 있습니다.

인프런 커뮤니티 질문&답변

Schema에서 DTO로 상속하는 과정에서 Decorator와 required 초기화 관련 질문입니다.