Un mio collega è contrario all'uso di DTO e ritiene piuttosto che dovremmo restituire gli oggetti Entity / Domain serializzati per un api REST. Sente che DTO è un modello anti e si trova in questo articolo Data Transfer Object è una vergogna . Sebbene l'articolo abbia un approccio diverso per risolvere il "problema DTO" come propone il mio collega. Personalmente ho sempre preferito utilizzare DTO per tre motivi.
- La mia API non è legata al mio livello di dominio, quindi ho flessibilità. Il livello del dominio può cambiare senza impatto sull'API e viceversa.
- Quando si usano ORM come JPA / Hibernate, non accidentalmente inviano tonnellate di query per costruire il grafico degli oggetti per la serializzazione, o devo mettere logiche / annotazioni nel mio livello di entità per controllare la serializzazione, che è davvero una preoccupazione di vista non un preoccupazione del dominio.
- Posso facilmente controllare cosa e quante informazioni passano sul filo, IE invia la manciata di campi che il cliente desidera anziché 30 campi.
Il punto 2 non è un grosso problema se un ORM non viene utilizzato. Riesco ancora a vedere se il problema si presenta anche se hai qualcosa di simile al seguente
class Order {
private Long orderId;
// additional fields go here
private List<LineItem> lineItems;
}
class LineItem {
private Long id;
private BigDecimal amount;
private int qty;
}
Diciamo che il cliente desiderava solo un elenco di ordini e non si preoccupava degli elementi pubblicitari. Se non fosse coinvolto un DTO, è possibile popolare l'oggetto Order e lasciare i lineItems come una lista vuota, ma ciò sarebbe scomodo e confuso per popolarlo in alcuni casi, e non in altri. O tutti i dati potrebbero essere caricati e trasferiti, ma ciò sembra uno spreco e un potenziale impatto sulle prestazioni.
C'è un momento appropriato per saltare le DTO e restituire semplicemente l'oggetto dominio? O sto pensando male e DTO non è un modello che dovrebbe essere usato. C'è un altro approccio?