Questo post chiude il giro sui DTO (o ViewObjects).
Nello scorso post abbiamo visto una soluzione sufficientemente elegante per implementare dei DTO usando delle classi Wrapper attorno agli oggetti del DM.
Tale soluzione è per quel che ho visto la più utilizzata ma in questo post vorrei mostrare una terza implementazione possibile.
L'unica pecca della soluzione precedente della classe wrapper è che il DTO dipende dall'oggetto del DM in quanto al suo interno ha un riferimento alla classe Employee.
Per svincolarci anche da questo legame possiamo costruire una classe che contiene solo le proprietà da portare sull'interfaccia senza però dipendere dal DM. Ad esempio:
public class EmployeeDTO
{
private String _name;
private String _fullAddress;
public String Name
{
get { return _name; }
set { _name = value; }
}
public String FullAddress
{
get { return _fullAddress; }
set { _name = _fullAddress; }
}
}
Naturalmente in questo modo sorge un altro problema. Chi ha il compito di riempire questa classe? Sarà il service layer ad occuparsi del mapping di oggetti del DM con oggetti DTO e viceversa.
Quindi questa soluzione, benchè più indipendende, crea un'altra dipendenza, seppur di minore impatto, nel service layer, inoltre, ha la scomodità di doversi scrivere una serie di metodi di conversione DM->DTO e DTO->DM.
Marco in un suo post ha ripreso l'argomento dal punto di vista dei servizi e questo post in qualche modo si riaggancia al suo e risponde anche ad un suo commento al post precedente.
Design