Separare le preoccupazioni con Linq To SQL e DTO

Question

Recentemente ho avviato un nuovo progetto di moduli web e ho deciso di separare le classi aziendali da qualsiasi riferimento DBML.Le mie classi del livello aziendale accedono invece a metodi discreti del livello dati e vengono restituite raccolte di DTO.Quindi il livello dati potrebbe proiettare DTO come il seguente:

(from c in dataContext.Customers
where c.Active == true 
select new DTO.Customer
{
   CustomerID = c.CustomerID,
   Name = c.CustomerName,
   ...
}).ToList()

Sebbene la creazione degli oggetti DTO aggiunga lavoro, questo sembra un approccio migliore per uno stretto legame tra i livelli Business e Dati e significa che posso testare il livello Business senza che sia presente un database.

La mia domanda è: è una buona pratica? Esiste un modo per generare DTO (magari tramite SQLMetal) e quali altri problemi potrei riscontrare man mano che il progetto avanza.

Answer 1

Non so se sia la pratica migliore, ma ho scritto codice simile in un passato non così recente perché anch'io sentivo che avrei potuto migliorare la separazione delle preoccupazioni utilizzando le mie classi invece di quelle generate da LINQ designer all'interno della mia applicazione .

Potresti prendere in considerazione la possibilità di restituire semplicemente un IQueryable<Customer> anziché un IList<Customer> dal tuo metodo di accesso ai dati.Poiché IQueryable<T> eredita da IEnumerable<T>, il resto della tua app dovrebbe essere in grado di gestirlo abbastanza bene.Puoi anche convertirlo in un elenco quando ne hai veramente bisogno.

Il vantaggio di ciò è che puoi modificare dinamicamente la tua query in modo abbastanza semplice e ridurre al minimo la quantità di dati restituiti da SQL Server.

Per esempio.Se la tua firma del metodo è iqueryableu003CCustomer> GetCustomers () potresti ottenere un singolo cliente chiamando getCustomer (). Dove (c => c.customerid == 101) .single ();

In questo esempio verrebbe restituito solo un record dal database mentre immagino che attualmente il tuo codice restituirebbe tutti i clienti oppure ti verrebbe richiesto di scrivere metodi separati (e quindi codice molto ripetitivo) per soddisfare tutte le diverse cose che potresti desiderare per filtrare.

Answer 2

A mio avviso, nella maggior parte dei casi gli oggetti DTO non sono necessari quando si ha a che fare con LINQ.Le classi LINQ generate possono essere facilmente testate.LINQ ti dà la possibilità di interrogare i tuoi dati da origini diverse utilizzando query identiche.Ti dà la possibilità di testare le tue query rispetto a elenchi di oggetti anziché a db reali.