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 Sunday, October 28, 2007 5:38 PM