> For the complete documentation index, see [llms.txt](https://kinesis-school-of-programming.gitbook.io/nestjs-unleashed/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kinesis-school-of-programming.gitbook.io/nestjs-unleashed/core-module-backend-development-with-nestjs/dto-limitations.md).

# DTO Limitations

DTOs offer a great way to validate incoming data, but they are not completely devoid of downsides.

As we know, we are using the **DTO** pattern to validate incoming data. Even though DTO validation is powerful and practical, there are some drawbacks to it, which will be discussed now.

One of the downsides of using DTOs is that there must be an **exact match** between its own fields' names and the ones from the incoming data. For instance, if in a certain route I want to validate an <mark style="color:blue;">`id`</mark> that has a different name, for example <mark style="color:blue;">`userId`</mark>, then the <mark style="color:blue;">`IdDto`</mark> could not be employed in this case, requiring another DTO that matches the field name.

> Thanks to **Jay McDoniel** for [his insight](https://stackoverflow.com/questions/75288812/nestjs-is-it-possible-to-reuse-same-dto-validation-with-different-field-names) (Stack Overflow)

Also, only a single DTO can be used in each one of the three ways to receive data (<mark style="color:blue;">`@Body()`</mark>/<mark style="color:blue;">`@Param()`</mark>/<mark style="color:blue;">`@Query()`</mark>). Right now, this may seem like an intimidating downside that may hinder us when developing truly enterprise-grade systems.

Even so, these are not necessarily reasons to stop using DTOs. A bit of work may be required to get around these problems, but there are some interesting solutions, one of which we'll learn about in the next section.