L'utilizzo dei DTO semplifica e ottimizza lo scambio di dati escludendo i campi non necessari e fornendo solo i dati di cui uno specifico client ha effettivamente bisogno.

I DTO in questo esempio servono a limitare lo scambio di dati tra client e server. Il ResponseBookDTO viene utilizzato per inviare solo i dati necessari (name, author, price) al client, mentre il RequestBookDTO consente ai client di inviare i dati richiesti (date, name, author, price) al server.

Il principale vantaggio dell'utilizzo dei DTO è che aiutano a separare i dati dalla logica di business e permettono di controllare quali dati vengono trasferiti tra i livelli dell'applicazione o inclusi nei messaggi di risposta HTTP.

Dove si applica il DTO?

I DTO vengono utilizzati quando è necessario presentare i dati in un formato specifico, ad esempio per trasferire dati a un client o ricevere informazioni da un client nel contesto di una REST API.

Questo è anche rilevante durante l'interazione tra i livelli in un'architettura multilivello, dove i dati vengono trasmessi tra servizi e repository.

Esempio reale

Immagina di sviluppare un'applicazione per un negozio online. Hai un'entità chiamata Product, che include molte informazioni: name, description, price, production date, discounts e così via.

Un client che richiede una lista di prodotti non ha bisogno di tutte queste informazioni. Invece, puoi creare un oggetto DTO che contiene solo i campi necessari (come il nome e il prezzo) per inviare questi dati al client.

Esempio di utilizzo

Nella nostra applicazione, il modello principale è Book, che viene inviato dal client e restituito dal server.

Tuttavia, non sembra che il campo id sia superfluo quando si ricevono dati dal client, poiché viene generato a livello di repository. L'id sarà necessario solo quando si restituisce una risposta.

Qui entrano in gioco i DTO. Consentono di separare la logica e creare diverse versioni del modello Book per richieste e risposte, escludendo campi non necessari come id dove opportuno.

In un DTO, un oggetto con il prefisso request viene utilizzato per inviare dati dal client al server, mentre un oggetto con il prefisso response viene utilizzato per inviare dati dal server al client. Questa separazione garantisce che vengano scambiati solo i dati necessari, migliorando sia la sicurezza che l'efficienza.

Ora abbiamo due DTO: uno per ricevere le richieste BookRequestDTO e un altro per inviare le risposte BookResponseDTO.

Si può notare che BookResponseDTO e il nostro modello Book sono identici, il che solleva la domanda: perché creare un DTO separato se possiamo semplicemente usare il modello Book?

La motivazione è che, se in futuro decidessimo di aggiungere informazioni aggiuntive necessarie solo a livello di servizio, il nostro modello Book finirebbe per trasmettere dati non necessari al livello di repository, richiedendo di filtrarli in qualche modo.

Mapper

Per trasformare comodamente oggetti da un tipo a un altro, si utilizza una libreria specializzata.

È possibile creare una classe separata in cui si definiscono metodi statici e si implementa la logica per la conversione degli oggetti tra tipi.

In questo codice, la classe MapperBook utilizza la libreria ModelMapper per la trasformazione automatica degli oggetti.

Contiene due metodi: il primo è dtoRequestToModel(), che trasforma un oggetto BookRequestDTO in un modello Book utilizzando il metodo map, e il secondo è modelToResponseDto(), che converte un modello Book in un oggetto BookResponseDTO.

Grazie a ModelMapper, il processo di trasformazione degli oggetti diventa più semplice e più pratico, eliminando la necessità di copiare manualmente i campi.

Aggiunta di un DTO alla nostra applicazione

Riepilogo

DTO (Data Transfer Object) è un oggetto semplice progettato per il trasferimento di dati tra layer o componenti di un'applicazione.

Nel contesto di un'architettura a tre livelli, il DTO svolge un ruolo cruciale garantendo la separazione dei layer e fornendo un modo efficiente per scambiare dati tra di essi.

Pertanto, l'utilizzo di un DTO rappresenta una soluzione ottimale quando è necessario gestire informazioni tra diverse parti di un'applicazione, evitando il trasferimento di dati non necessari o irrilevanti.