DTO un'altra possibile implementazione


Nell'ultimo post abbiamo implementato un semplice DTO sfruttando l'ereditarietà ma ci siamo accorti di alcuni problemi che la soluzione porta con se. In chiusura abbiamo citato il principio "Favor encapsulation over inheritance".
Cosa vuol dire?
Vuol dire che il DTO invece di ereditare da Employee lo dovrebbe incapsulare.
Vediamo il codice:

public class EmployeeDTO 
{
    private Employee _employee;
    
    public EmployeeDTO(Employee employee)
    {
        _employee = employee;
    }

    public String Name
    {
        get { return _employee.Name; }
    }

    public String FullAddress
    {
        get { return String.Format("{0}, {1}", 
_employee.Address.Street, _employee.Address.City); } } }


Questa soluzione, benchè più prolissa, risulta molto più flessibile e comoda da utilizzare. L'oggetto EmployeeDTO fa da wrapper attorno a Employee e ci permette di aggiungere tutte le proprietà che vogliamo senza dipendere dal Domain Model l'unico svantaggio è il lavoro noioso di remapping delle proprietà che non devono essere trasformate (ad esempio Name ).

Da notare che questa soluzione permette di incapsulare più oggetti nello stesso DTO.
L'unico piccolo svantaggio è che EmployeeDTO dipende da Employee e sebbene più libero della sua implementazione precedente ha ancora qualche vincolo.

[Continua...]

Nota: Papo mi faceva notare come l'implementazione precedente e anche la presente non possa essere definita a tutti gli effetti un DTO. In effetti ad essere precisi è vero, non è un vero DTO perchè la proprietà FullAddress contiene della logica applicativa, ma essendo solo logica di presentazione è accettabile che stia in un DTO. Comunque per i più formali nella prossima puntata arriveremo al "DTO puro".

Print | posted on domenica 28 ottobre 2007 17.38

Comments on this post

# re: DTO un'altra possibile implementazione

Requesting Gravatar...
Una domanda... sembrerà banale, ma...
ha senso??

Boh... un domain model di un'applicazione medio-grande può avere tranquillamente 3-400 oggetti, ha senso mettersi a fare anche questi DTO?

Perché complicarsi in questo modo la vita? Tra l'altro, non mi piace il fatto che tu imposti la rappresentazione dell'indirizzo nella classe Employee, se poi hai l'oggetto Edificio, anch'esso con un indirizzo, sei costretto a scriverne una versione di FullAddress anche lì. Io avrei messo il FullAddress sull'indirizzo, e magari avrei usato direttamente il ToString().

BTW, il mio commento non vuole essere polemico, eh... solo uno spunto di discussione!
Left by Marco De Sanctis on ott 29, 2007 2.34

# re: DTO un'altra possibile implementazione

Requesting Gravatar...
composition over inheritance rocks!
Left by makka on ott 29, 2007 10.14

# re: DTO un'altra possibile implementazione

Requesting Gravatar...
@ Marco: io non credo che sia inutile. Tieni conto che i DTO (o View) non sono in associazione 1:1 con gli oggetti del DM. In genere fai un DTO per ogni aggregato (o a volte per ogni form).
In passato ho avuto progetti in cui sporcavo il DM con override di metodi ToString o altre proprietà composte e a lungo andare la cosa era scomoda da gestire e porta a "rovinare" il DM.
Naturalmente imho.
PS Magari meglio spostare la discussione su Guisa.
Left by Emanuele DelBono on ott 29, 2007 6.06

# domain names » DTO un’altra possibile implementazione

Requesting Gravatar...
domain names » DTO un’altra possibile implementazione
Left by on ott 30, 2007 2.05

Your comment:

 (will show your gravatar)
 
Please add 4 and 8 and type the answer here: