Data Transfer Object (DTO) vs Value Object (VO)
Massimo S.
Pure in questo caso ho trovato "pareri" contrastanti.
Alcuni dicono che sono esattamente la stessa cosa, che sono sinonimi.
Un mio collega dice che i vo si usano per passare i dati tra i vari
layer: dao -> bussiness -> presentation mentre i dto si usano (ad
esempio in ambito struts 1.x) per passare i dati da le action e le jsp
e viceversa ed inoltre che i dto devono avere tutti i campi di tipo
String, anche quelli che nei corrispettivi vo sono di altro tipo come
int.
Su un altro sito avevo letto, al contrario, che i dto si usano per
passare i dati tra i layer mentre i vo si usano solo in presentazione
e devono avere un ciclo di vita breve.
Pure qui qualcuno mi può dare delucidazioni?
Grazie
cicap
> Pure qui qualcuno mi può dare delucidazioni?
I DTO servono per passare dati tra i vari sottosistemi di un'applicazione.
La Sun ha cominciato con chiamarli VO, per poi ricredersi a rinominarli in
DTO.
Il termine VO esiste da prima di Java, ed è descritto qui:
http://c2.com/cgi/wiki?ValueObject
Diciamo che la Sun ha fatto un gran casino ;)
Massimo S.
Provo a buttare un altro po di carne sul fuoco :-)
Ho letto che il DTO sarebbe diventato un antipattern (cioè non va
usato) se si usa qualcosa tipo hibernate o gli entity beans di EJB 3.0
Che ne pensate?
E già che ci siamo: ha senso usare il pattern DAO insieme a hibernate
o gli entity beans di EJB 3.0 ?
cicap
Innanzittutto non mi sembra che chiedere curiosità sia il modo
corretto di approfondire l'argomento Design Pattern.
Comunque, i DTO servono a passare dati tra due sottosistemi. Qualora
vi fosse questa necessità, non vedo perchè debbano costituire un
antipattern.
In generale Hibernate consente un mapping di alto livello tra il tuo
dominio ad oggetti e il mondo relazionale dei database. Per questo
motivo può eliminare la necessità di un DTO tra lo strato di
persistenza e quello di business.
Ma rimangono aperti altri ambiti. Nei webservice, ad esempio, l'uso
dei DTO non è eliminabile.
I DAO hanno senso anche con EJB3, se ne senti la necessità. La cosa
interessante è che con EJB3 un DAO può tranquillamente essere
implementato tramite session bean:
@Stateless
public class UserDaoBean implements UserDao {
@PersistenceContext
EntityManager em;
...
}