Quando sviluppiamo applicazioni usando metodologie DDD e quindi creando un domain model capita spesso di avere la necessita di aggiungere proprietà composte che hanno lo scopo di appiattire il grafo degli oggetti per semplificare il binding dei dati sull'interfaccia utente.
Per capire meglio il contesto consideriamo il seguente esempio dell'oggetto Employee:
public class Employee
{
private String _name;
private Address _address;
public string Name
{
get { return _name; }
set { _name = value; }
}
public Address Address
{
get { return _address; }
set { _address = value; }
}
}
public class Address
{
private String _street;
private String _city;
public string Street
{
get { return _street; }
set { _street = value; }
}
public string City
{
get { return _city; }
set { _city = value; }
}
}
Supponiamo che ci venga richiesto di visualizzare in un elenco (un GridView) tutti gli Employee con nome e indirizzo completo. Purtroppo ASP.NET non supporta il binding di oggetti annidati (WPF si) quindi non posso "bindare" la proprietà "Address.Street" alla GridView.
La prima soluzione che ci viene in mente è quella di rimappare la proprietà Address dell'oggetto Employee in questo modo:
public classs Employee
{
// ....
public String FullAddress
{
get { return String.Format("{0}, {1}", Address.Street, Address.City;}
}
}
Cosi facendo il binding torna ad essere semplice ma il Domain Model viene sporcato con proprietà non tipicamente legate al contesto applicativo e con il passare del tempo, e il crescere del numero di proprietà di supporto al binding, il DM diventa difficile da mantenere e meno rappresentativo della logica di business perchè pieno di "frills" per gestire la visualizzazione dei dati.
Come si può risolvere il problema in modo elegante tenendo il DM integro?
Introducendo il concetto di DTO (Data Transfer Object) cioè semplici oggetti che hanno lo scopo di portare le informazioni sull'interfaccia utente.
[continua....]