Volevo lasciare un commento al post di Igor, poi ne è venuto fuori un papiro e allora è meglio scrivere qui.
A mio modo di vedere, c'è un errore di fondo nel concetto di DTO espresso in quel post. Un DTO, infatti, *NON* deve né ereditare, né incapsulare l'oggetto che rappresenta; anzi... dirò di più: un DTO non deve avere alcuna relazione con l'entità (o le entità) di dominio che rappresenta, altrimenti non sarebbe un DTO!!
Cerco di spiegare meglio il concetto. Perché creo ed espongo un DTO? Una delle ragioni può essere che non voglio/posso esporre direttamente una mia entity di dominio. E allora che senso ha creare un DTO che la incapsula? o da cui eredita? Finirei comunque per esporla, no?
In realtà, il DTO ha un significato più ampio: è semplicemente un modo per codificare un particolare messaggio rappresentandolo in forma di oggetto, e non necessariamente è mappato 1-1 con le entità di un domain model (diciamo pure che in generale, ha decisamente poco a che vedere con esse).
Nel caso di Igor, volendo creare un DTO per l'oggetto Fattura, probabilmente realizzerei qualcosa del genere:
1 [DataContract]
2 public class FatturaDTO
3 {
4 [DataMember]
5 public string Numero;
6 [DataMember]
7 public DateTime Data;
8 [DataMember]
9 public string RagioneSocialeCliente
10 ...
11 }
(notare la proprietà RagioneSocialeCliente), magari con un costruttore che accetti un'istanza di "Fattura" e popoli i relativi field. Le stringone XML di questo esempio di Igor sono anch'esse dei DTO, magari in senso lato (ma neanche troppo).
BTW, sicuramente si tratta di un approccio dispendioso, che personalmente adotterei solo se ho vincoli che mi impongono una SOA rigorosa. Mi capita spesso, nel lavoro di tutti i giorni, di dover esporre servizi a client Java o PL/SQL, o magari di esporli e basta, senza sapere chi mai li invocherà, con in mano solo un documento di specifiche di forma da rispettare. E in quel caso allora è necessario specificare un insieme di messaggi che standardizzino il protocollo di comunicazione con i miei servizi e che restino immutabili anche a seguito di eventuali modifiche che un giorno farò al mio domain model. I DTO, per l'appunto.
Molto spesso però - e questo mi sembra proprio il caso di Igor - la reale necessità non è quella di esporre servizi a terze parti, ma semplicemente quella di avere un'applicazione distribuita, pur mantenendo stretto controllo di ciò che è in esecuzione sul client e sul server. Per dirla in parole povere, me ne frego dell'interoperabilità e non espongo nulla a nessuno, voglio solo avere la possibilità di interfacciarmi da remoto con una parte della mia applicazione.
Ottimo. Beh, in questi casi non vedo controindicazioni ad utilizzare direttamente le entity del domain model, se possibile. Dirò di più, magari voglio avere gli stessi tipi di oggetti sia sul client che sul server. Di SOA non ha neanche la più lontana parvenza, ma chi se ne frega? non mi serve avere un'architettura orientata ai servizi.
Allora, in uno scenario simile può essere utile anche questo tip.
http://blogs.ugidotnet.org/Crad/archive/2007/04/02/74468.aspx
Ah... last but not least: invece che con DataContract, i servizi WCF funzionano benone anche con entity marcate semplicemente come Serializable. 
Technorati tags:
WCF,
DTO,
SOA