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 id that has a different name, for example userId, then the IdDto could not be employed in this case, requiring another DTO that matches the field name. (Thanks to Jay McDoniel for his insight)

Also, only a single DTO can be used in each one of the three ways to receive data (@Body()/@Param()/@Query()). Right now, this may seem 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 in the next section.