Il modello DTO è deprecato o no?

Question

In un'applicazione Java EE completa in cluster il modello DTO è ancora un'opzione valida? L'applicazione in questione usa EJB Hibernate e Struts con Spring etc. C'è qualcosa di sbagliato nel trasferimento di oggetti di dominio in uno scenario del genere?

EDIT: Giusto per chiarire la mia domanda, con le risorse moderne e i miglioramenti in Java EE c'è un motivo per non utilizzare solo oggetti di dominio? Se non c'è, allora il modello DTO non si dissolve e non dovrebbe essere usato nelle nuove applicazioni?

Answer 1

Non obsoleto. Dipende dall'architettura dell'applicazione se il pattern DTO deve essere usato o meno. Ad esempio, quando sviluppi servizi Web (usando JAX-WS o JAX-RS), devi inviare DTO sui tuoi metodi web in modo che un C# o un'applicazione client Python possa consumarlo, e il tuo metodo web non dovrebbe restituire un oggetto di classe Annotazioni Hibernate, ricorda che in altre lingue l'Entità non verrà creata con quelle annotazioni o altre logiche di business all'interno.

---

MODIFICA (in base al tuo commento): Dipende dall'architettura del software. Ad esempio, sto lavorando a un progetto SOA e utilizziamo DTO per il livello dei servizi e il livello di presentazione. Più approfonditi, utilizziamo anche DTO per gestire le comunicazioni del database all'interno dei servizi, usiamo solo gli SP per comunicare con DB, quindi nessun Hibernate o altri strumenti ORM possono funzionare lì, potremmo usare Spring DAO e tale framework utilizza anche DTO. Al giorno d'oggi è possibile trovare molti schemi DTO in molte applicazioni.

Maggiori informazioni che sarebbe grande per questa domanda:

• Difference between DTO, VO, POJO, JavaBeans? (dove in sostanza, qualsiasi DTO è un POJO).
• Core J2EE Patterns - Transfer Object

EDIT 2: Un'altra fonte di informazioni che spiegherà il motivo principale per l'utilizzo di progettazione di DTO, spiega con Martin Fowler

• LocalDTO

Conclusione: DTO non un sono anti modello. I DTO sono pensati per essere utilizzati solo quando è necessario passare i dati da un sottosistema a un altro e non hanno un modo predefinito o standard per comunicare.

Answer 2

Un modello è puro design. Non c'è "deprecazione" di pattern, ma meno utilizzo nel tempo (o eccessivo utilizzo).
Personalmente, non vedo perché non usare i DTO.
Ad esempio - al progetto open source oVirt abbiamo entità che rappresentano entità di business logic nel dominio della virtualizzazione.
Queste entità devono essere annotate dalle annotazioni di Hibernate (in realtà, sono oggi, mentre abbiamo iniziato a lavorare sui POC di ibernazione) e funzionano come DTO e quindi pulire dagli oggetti di annotazioni che verranno mappati (ad esempio, utilizzando dozer framework) e utilizzato dal client
(non mi piace avere al codice lato client con annotazioni non necessarie), o le entità dovrebbero servire come oggetti client (oggetti valore) passati al client e dovremmo avere altre classi come Entità DTO

L'approccio di cui sopra è che si potrebbero avere 2 diagrammi di classi parallele - una per DTO e una per oggetti valore (che vengono utilizzati dai client) - ma, in molti casi in progettazione, c'è un trade- off.
Devi comprendere i vantaggi e gli svantaggi e scegliere ciò che è meglio per te (nel nostro caso, dal momento che il lato client è GWT, per noi sarà più facile separare due gerarchie di classi, una che è DTO/lato server e può anche essere annotato con più annotazioni lato server e l'altro inviato al codice cliente GWT).

Answer 3

È un modello molto utile in Java EE.

Uso un DTO per trasferire oggetti entità correlate dai bean EJB al livello dell'interfaccia utente. Gli oggetti entità vengono recuperati dal DB in una transazione (vedere TransactionAttributeType.REQUIRED) e archiviati nell'oggetto DTO. Il DTO è consumato nel livello dell'interfaccia utente.