Il fatto è che i DTO hanno lo scopo di trasportare dati dal dominio al di fuori di esso. Spesso i DTO servono a minimizzare le chiamate, soprattutto nelle architetture a servizi. Immaginiamo infatti di dover fare un ordine in questo modo.
Chiami il metodo CreateOrder ti ritorna un Order e poi per ogni linea d'ordine chiami un metodo AddOrderLineToOrder. Se hai un servizio remoto la latenza di rete rende questa operazione lenta. Questo perchè le interfacce dei domini sono solitamente fine grained, ovvero molti piccoli metodi per fare piccole cose.
In un ottica di comunicazione remota sono meglio le Coarse Grained Interfaces, ovvero meno metodi che svolgono operazioni più complesse. Nel caso precedente avresti un CreateOrder che accetta un unico DTO che contiene tutte le informazioni necessarie, ovvero anche tutte le linee d'ordine.
Il compito del presenter è si quello di mostrare le info tramite interfaccia, sempre nel caso analogo, se io volessi visualizzare un ordine chiamerei un metodo GetOrder, che torna un DTO con dentro tutte le info necessarie, ed è da li che il presenter decide cosa visualizzare. Anche in questo caso se ho un servizio remoto, bisogna capire se creare un DTO ad hoc con solo le informazioni disponibili è vantaggioso, anche perchè altrimenti mandi in giro per la rete informazioni inutili.
alk.
--
Non esiste vento favorevole per il marinaio che non sa dove andare. (Seneca)
blog:
Alkampfer's place[Eng] Alkampfer's place