Come utilizzare DTO tra UI, BLL, DAL

Question

Sto provando a scrivere una piccola app con limiti molto rigidi tra BLL e DAL e ora mi chiedo quale sarebbe il modo migliore per passare i dati (oggetti di trasferimento di dominio) tra gli strati.

Ho implementato alcune classi in un livello di dominio (libreria di classi) a cui si accede sia da BLL che da DAL. Queste classi fondamentalmente contengono solo proprietà/dati membri e attualmente riflettono i dati DAL. Es:

class CustomerData 
{ 
    // some data fields 
} 

Poi ho realizzato alcune classi in BLL come:

class Customer : CustomerData 
{ 
    // Some methods 
} 

Nel mio DAL ottengo i dati dei clienti dal database tramite LINQ to SQL. Ho poi mappare l'oggetto LINQ al mio oggetto Dominio da:

CustomerData.field = LinqObject.field 
// Etc 

Il mio pensiero è in tal modo che io ora un'istanza CustomerData dal mio DAL a BLL quando richiesto (e che avrei dovuto passare un istanza di Customer alla mia UI).

Nella mia BLL riceverò quindi un'istanza CustomerData, ma ora voglio farne un Cliente.

Domande:

1. Devo a mio BLL ora creare un'istanza del cliente e di nuovo copiare tutti i membri di campo?
   Cliente c = nuovo cliente; c.field = CustomerData.field;
2. Come posso creare un cliente da CustomerData senza le operazioni di copia campo?
3. Dovrei piuttosto usare la composizione?
   classe Cliente { Dati dati cliente; }
4. Esiste un modo più efficace (meno codifica, ecc.) Per eseguire questa operazione nel mio layout corrente?
5. Esistono modi migliori per farlo?
6. Eventuali commenti in generale?

Grazie!

Answer 1

in genere considero DTO non specifico di livello, creato/consumato da DAL, elaborato da BLL e consumato/creato dall'interfaccia utente.

di solito ogni livello è un progetto separato nella cartella della soluzione VS, pertanto i DTO sono un altro progetto a cui fa riferimento ogni livello.

in questo modo se c'è un campo che deve esistere nell'interfaccia utente ma non negli altri livelli, il DTO può essere ereditato da.

Answer 2

non si stanno utilizzando completamente DTO. Nella classe Customer, restituisci CustomerData direttamente nell'interfaccia utente.

e non v'è alcuna necessità di ereditare Customer da CustomerData

EDIT: ho usato la parola completamente qui perché CustomerData è DTO, così invece di tornare clienti, il ritorno CustomerData in quanto è il tuo DTO come si vede nella seguente diagramma.

Un suggerimento, è necessario utilizzare Repository Pattern per isolare BLL e DAL.

1]

Answer 3

Alcune note dal mio punto di vista viene qui, io non sono un oracolo, ma spero che vi darà qualche aiuto :)

Per me ci si sente di avere troppi " modelli "qui. Potrebbe causare confusione e portare a molto codice solo per copiare i dati tra diverse rappresentazioni. E molto codice indica più bug. Quindi, penso che l'ereditarietà tra classi di dati e tipi di classi di business ti limiti quando definisci le tue classi di business. Che ne dici se vuoi creare una business class composta da più classi di dati? Dovresti piuttosto usare le interfacce o la composizione che penso.

In genere, lavoro con un solo modello concettuale che riflette il dominio aziendale. Questo modello è utilizzato sia dai dati che dal livello aziendale e in alcuni casi anche dal livello di presentazione (nelle app più piccole), come sottolinea Dead Rabit. Per la persistenza utilizzo un O/RM come EF 4.

Per progetti di dimensioni maggiori, specialmente in scenari distribuiti, utilizzo DTO personalizzati per i layer UI. Queste classi riflettono le esigenze dell'interfaccia utente e potrebbero differire molto dalle entità nel modello concettuale.

Personalmente, penso che Entity Framework 4 sia di grande aiuto quando si costruiscono app in base a questa struttura, se si è nelle prime fasi del progetto e si utilizza .NET 4, si potrebbe voler verificarlo?

1. Sì, probabilmente è necessario.
2. Usa composizione
3. Sì, vorrei utilizzare composizione
4. usare per esempio Entity Framework 4
5. (- "-)
6. vedi sopra

Answer 4

Se si insiste per avere più strati su DTO, puoi usare AutoMapper per aiutarti a convertire da uno a un altro in una riga di codice (usando la stessa convenzione nei tuoi DTO)

CustomerData customerData = Mapper.Map<LinqObject, CustomerData>(linqObjectInstance); 

Si dovrebbe anche guardare il modello PresentationModel: http://martinfowler.com/eaaDev/PresentationModel.html

È possibile anche google per MVVM (Model-View-ViewModel), se si vuole andare in questo modo.