Si può andare con il modello di dominio appropriato, che può essere utilizzato su SL, BL e DAL. E per WebServices / WindowsService e per l'interfaccia utente utilizzerei il DTO appropriato, che potrebbe essere diverso ma che ha senso perché ogni servizio potrebbe esporre funzionalità diverse. Ad esempio, immagina che il dominio sia come
Order
{
long orderId { get; set;}
decimal value { get; set;}
Customer customer { get; set;}
List<Orderline> orderlines { get }
void Add(Product p,qty q)
{
orderlines.Add(new Orderline(){order = this, product = p,qty = q,unitPrice = p.unitPrice});
value += p.unitPrice * q;
}
}
Customer
{
long customerId { get; set;}
string firstName { get; set;}
string lastName { get; set;}
}
OrderLine
{
Order order { get; set; }
Product product { get; set;}
decimal qty { get; set;}
decimal unitPrice { get; set;}
}
Product
{
long productId { get; set;}
string productName { get; set;}
decimal unitPrice { get; set;}
}
E questo modello di dominio può essere persistente / contiene anche la logica di business. Quindi questo modello può essere utilizzato su SL / BLL / DAL.
Nel servizio web quando vuoi ottenere i dettagli dell'ordine, potresti voler mappare in un DTO come,
OrderWSDTO
{
long orderId { get; set;}
string customerName { get; set; }
}
OrderLineWSDTO
{
string productName { get; set;}
decimal quantity { get; set;}
decimal value { get; set;}
}
Tuttavia in UI (lista ordini) potrebbe essere una rappresentazione completamente diversa.
OrderSummaryUIDTO
{
string orderId { get; set;}
decimal value { get; set;}
string commaSeparatedProductNames { get; set;}
}
