Use DTO objects

[gy-szabo]

Right now we have endpoints that either require or provide the Customer entity objects. In order to save processing power and make the api more customisable, the api should only accept and provide DTO objects.

In code this means:

• creating a CustomerDTO and a CustomerListItemDTO class
• in the controller class these DTOs should be the parameter type and the return type of each endpoint
• the service layer should also get DTOs as inputs and return DTO objects
• in order to make repository calls we still have to use the Customer object, therefore there should be a mapping process that converts a DTO to an entity, and an entity to a DTO

[gy-szabo]

Here is a typical scenario in real life apps:

• we have an entity that consists of 25 columns of data, a list endpoint and a get by id endpoint
• we have a table/list view on our frontend app, where we show a 100 of these entities, but we show only the most important fields (maybe 5 of the 25). This calls the list endpoint
• we can open a detailed view, where we see every data of the given entity. This calls the get by id endpoint

The get by id part is ok, let’s focus on the get list part.

If we see only 5 of the 25 columns of the data for each table row, why should we send more? If we send more than enough then we essentially increase the communication time between the api and client. Moreover, we might even create larger db queries, therefore making the db communication slower as well. This is a problem, but it can be solved.

This is where DTOs come in. DTOs are basically objects that in terms of data are either:

• equal to the entity (we use these usually when we need every detail, e.g. a detailed view on the frontend)
• a subset of the entity (e.g. the part of the object that we see in tables on the frontend)