The app defines a number of DTOs /data objects that are used to encapsulate and validate all the parameters used to filter lists of entities (short URLs, visits, etc).
They are kindof useful, but they also introduce more levels of indirection.
The problem gets worst considering there are usually two levels of DTOs, those closer to the action, which include validation, and usually handle itemsPerPage and page together with the rest of filtering arguments, and then a second level closer to the DB abstraction/repository which handles limit and offset and does not validate the arguments.
Converting the first level into the second level becomes cumbersome and adds a lot of boilerplate code.
The problem is even worst considering we usually have two objects per use case in the lower level, one with limit and offset for lists of entities, and one without it to count lists of entities. This means we have at least three DTOs per use case.
Proposal
I would explore the option to merge all objects for the same use case, and see if it makes things better or worst.
We could have objects which can be created from pagination params or limit and offset, and internally do the conversion to the latter if needed.
We could also avoid splitting objects for listing and counting, and simply ignore limit/offset for the latter. This could be unintuitive though, so let's see.
Starting with a POC refactoring one of the use cases would be a good starting point.
The app defines a number of DTOs /data objects that are used to encapsulate and validate all the parameters used to filter lists of entities (short URLs, visits, etc).
They are kindof useful, but they also introduce more levels of indirection.
The problem gets worst considering there are usually two levels of DTOs, those closer to the action, which include validation, and usually handle
itemsPerPageandpagetogether with the rest of filtering arguments, and then a second level closer to the DB abstraction/repository which handleslimitandoffsetand does not validate the arguments.Converting the first level into the second level becomes cumbersome and adds a lot of boilerplate code.
The problem is even worst considering we usually have two objects per use case in the lower level, one with
limitandoffsetfor lists of entities, and one without it to count lists of entities. This means we have at least three DTOs per use case.Proposal
I would explore the option to merge all objects for the same use case, and see if it makes things better or worst.
We could have objects which can be created from pagination params or limit and offset, and internally do the conversion to the latter if needed.
We could also avoid splitting objects for listing and counting, and simply ignore limit/offset for the latter. This could be unintuitive though, so let's see.
Starting with a POC refactoring one of the use cases would be a good starting point.