cosa è un buon modello per la conversione tra le entità Hibernate e oggetti di trasferimento dei dati?

Question

ho avuto domande e preoccupazioni simili su come per la conversione tra le entità Hibernate e il trasferimento dei dati oggetti da restituire da un servizio Web come sono discussi in questa domanda:

sta usando oggetti di trasferimento dati in EJB3 considerato il miglior praticare

Uno dei fattori menzionati qui è che se il modello di dominio modifiche, una serie di DTOs proteggerà i consumatori nel caso di un servizio web.

Anche se sembra che aggiungerà una notevole quantità di codice al mio progetto, questo ragionamento sembra suono.

C'è un buon design pattern che posso usare per convertire un'entità Hibernate (che implementa un'interfaccia) ad un DTO che implementa la stessa interfaccia?

Quindi, supponendo sia dei seguenti implementare 'Book', avrei bisogno di convertire un BookEntity.class ad un BookDTO.class modo che io possa lasciare JAXB serializzare e ritorno.

Ancora una volta, tutta questa prospettiva sembra discutibile per me, ma se ci sono buoni modelli là fuori per aiutare ad affrontare questa conversione, mi piacerebbe avere una certa comprensione.

C'è forse un modo interessante per convertire attraverso la riflessione? O un modello di 'costruttore' che non sto pensando?

devo solo ignorare il modello DTO e passare entità intorno?

Answer 1

devo solo ignorare il modello DTO e superare le entità in giro?

La mia preferenza è di solito "sì". Non mi piace l'idea di gerarchie parallele create solo per il gusto di purezza architettonica o un livello.

Il motivo originale per il modello DTO è stata eccessiva loquacità in EJB 1.0 e 2.0 le applicazioni quando si passa EJB di entità al livello vista. La soluzione era quella di mettere lo Stato bean di entità in un DTO.

Un altro motivo che di solito è dato per creare DTOs è vietare modifica da parte del livello vista. DTOs sono oggetti immutabili in questo caso, con nessun comportamento. Fanno dati nient'altro che dei traghetti per lo strato di visualizzazione.

Direi che DTO è un modello core J2EE che è diventato un anti-modello.

Mi rendo conto che alcune persone non sarebbero d'accordo. Sto semplicemente offrendo la mia opinione. Non è l'unico modo per farlo, né necessariamente il modo "giusto". E 'la mia preferenza.

Answer 2

Non ci deve essere una visione contrarian tra tutti i jolly calciando del DTO.

tl;. Dr - A volte è ancora utile

Il vantaggio del DTO è che non c'è bisogno di aggiungere un triliardo di annotazioni ai tuoi classi di dominio.

Si inizia con @Entity. Non così male. Ma allora avete bisogno JAXB quindi si aggiunge @XMLElement ecc - e quindi è necessario JSON in modo da aggiungere cose come @JsonManagedReference per Jackson a fare la cosa giusta con i rapporti quindi si aggiunge ecc ecc ecc all'infinito.

Ben presto il tuo POJO non è così semplice più. Leggi "dominio guidato il design" qualche volta.

In aggiunta è possibile "filtro" alcune proprietà che non si vuole la vista di conoscere.

Answer 3

Non dobbiamo dimenticare che gli oggetti di entità non sono facili da gestire quando si trovano in stato gestito. Questo rende il loro passaggio alla GUI forma problematica. Per essere più precisi, gli oggetti figlio vengono gestiti con entusiasmo. Questo non può essere fatto fuori seduta, cousing eccezioni. Così, essi o essere sfrattati (monofamiliare) dal gestore di entità di essi devono essere convertiti in DTOS appropriate. A meno di cource v'è un modello, che io non sono a conoscenza, che sarei stato molto contento di sapere.

Answer 4

Per creare rapidamente un "sosia" DTO, senza un po 'di duplicato get / set di codici, è possibile utilizzare BeanUtils.copyProperties . Tale funzione aiutare a copiare rapidamente i dati da DAO alla classe DTO. Basta ricordare che ci sono più di un librerie comuni supportano BeanUtils.copyProperties, ma la loro sintassi non sono gli stessi.

Answer 5

So che questo è una vecchia questione, ma il pensiero vorrei aggiungere una risposta che offre un quadro di aiuto nel caso in cui qualcun altro sta affrontando questo problema.

Il nostro progetto è JAXB annotato POJO che sono separati dai JPA annotata POJO. La nostra squadra stava discutendo il modo migliore per spostare i dati tra i due oggetti (in realtà strutture dati).

Ecco un opzione per le persone a prendere in considerazione:

Abbiamo trovato e stanno sperimentando con Bulldozer che le maniglie (1) lo stesso nome, (2) la mappatura XML e (3) le conversioni personalizzato come modi per copiare i dati tra due POJO.

E 'stato molto facile da usare finora.