Il DTO dovrebbe avere la stessa struttura del carico utile?

Question

Il DTO dovrebbe avere la stessa struttura del carico utile?

#1 da (4 voti)

6

Ho un usecase in cui dovrei immagazzinare l'intero carico utile da un'API di terze parti oltre al DTO, ad esempio XYZDto, tradotto in.

Ci sono due modi per farlo -

Traduci il carico utile in DTO così com'è e quando si tratta di convertirlo in entità corrispondente, farei entity.apiPayload = convertToJson(dto)
Un altro modo è quello di avere un campo di payload in dto stesso e scrivere il mio mapper che esegue quanto segue.

a. Esegui il solito carico utile per la conversione DTO

b. Memorizza il carico utile in DTO dto.apiPayload = payload In questo modo il carico utile sarà già pronto durante la conversione in entità e faremo solo entity.apiPayload = dto.apiPayload

Come comprendo, il vantaggio dell'opzione 2 è che non ci sarà una traduzione non necessaria di dto back to payload in fase di runtime.

Voglio capire se c'è un modello di progettazione o una regola che sto rompendo qui. Mi mancano eventuali compromessi tra DTO che hanno la stessa struttura del suo payload rispetto a una struttura diversa?

java8 spring dto

posta comiventor 25.12.2017 - 18:07

fonte

1 risposta

Leggi altre domande sui tag java8 spring dto

Quali sono le implementazioni di SOA oltre ai servizi web? [chiuso] Motivo per utilizzare le intestazioni e le librerie mingw win32 con LLVM / Clang

score 4 · Accepted Answer

Lascia che riformuli la tua domanda in un modo più generale:

ci sono due diverse rappresentazioni dello stesso blocco di dati (qui una rappresentazione DTO e una rappresentazione JSON)
ci sono diverse fasi di elaborazione, alcune che richiedono la prima rappresentazione, altre che hanno bisogno del secondo

Dovrebbe uno

usa solo una rappresentazione alla volta e converti nell'altra su richiesta o
mantiene entrambe le rappresentazioni affiancate, quindi non è necessaria alcuna conversione successiva?

L'opzione 1 è sicuramente necessaria se le fasi di elaborazione intermedie possono modificare il contenuto dei dati, altrimenti il risultato sarà errato. Ad esempio, quando nei passaggi tra "convertire il carico utile in DTO" e "convertirlo in una stringa JSON" il contenuto del DTO cambia, il payload originale non corrisponderebbe più al contenuto del DTO.

Opzione 2, tuttavia

potrebbe essere più veloce (nota questo se spesso trascurabile)
potrebbe richiedere il doppio della memoria (nota questo se spesso anche trascurabile)
potrebbe essere più semplice quando si risparmia la necessità di scrivere il codice di conversione in una direzione (nell'esempio, l'implementazione di convertToJson potrebbe non essere più necessaria - ma si noti che questo vantaggio svanisce se il codice di backconversion è ancora richiesto per altri scopi)
potrebbe essere richiesto se si desidera la rappresentazione originale dei dati al 100% identica, inclusi metadati, commenti, spazi bianchi e così via, e la funzione "conversione indietro" (come convertToJson ) non facilmente garantire questa precisione
può introdurre errori se una delle due rappresentazioni non è mantenuta immutabile (come ho già scritto sopra)

Quindi questo è un compromesso, analizza le tue esigenze in contrasto con i punti che ho citato sopra, quindi scegli la tua scelta.