Separando preocupações com Linq To SQL e DTO's

Question

Recentemente, iniciei um novo projeto de webforms e decidi separar as classes de negócios de quaisquer referências DBML.Em vez disso, minhas classes da camada de negócios acessam métodos discretos da camada de dados e são retornadas coleções de DTOs.Portanto, a camada de dados pode projetar DTOs como o seguinte:

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

Embora a construção de objetos DTO acrescente trabalho, esta parece ser uma abordagem melhor para uma ligação estreita entre as camadas de Negócios e Dados e significa que posso testar a camada de Negócios sem a presença de um banco de dados.

Minha pergunta é: isso é uma boa prática? Existe uma maneira de gerar DTOs (talvez via SQLMetal) e que outros problemas posso encontrar à medida que o projeto avança.

Answer 1

Não sei se é uma prática recomendada, mas escrevi código semelhante em um passado não tão recente porque também senti que poderia melhorar a separação de interesses usando minhas próprias classes em vez das geradas pelo designer LINQ em meu aplicativo .

Você pode considerar apenas retornar um IQueryable<Customer> em vez de um IList<Customer> do seu método de acesso a dados.Como IQueryable<T> herda de IEnumerable<T> o resto do seu aplicativo deve ser capaz de lidar muito bem com isso.Você também pode convertê-lo em uma lista quando realmente precisar.

A vantagem disso é que você pode modificar dinamicamente sua consulta com bastante facilidade e minimizar a quantidade de dados retornados do SQL Server.

Por exemplo.Se a assinatura do seu método for iQueyableu003CCustomer> GetCustomers () você pode obter um único cliente ligando para getCustomers (). Onde (c => c.customerid == 101) .single ();

Neste exemplo, apenas um registro seria retornado do banco de dados, enquanto imagino que atualmente seu código retornaria todos os clientes ou você seria obrigado a escrever métodos separados (e, portanto, código muito repetitivo) para atender a todas as coisas diferentes que você deseja. para filtrar.

Answer 2

Na minha opinião, na maioria dos casos, os objetos DTO não são necessários ao lidar com LINQ.As classes LINQ geradas podem ser facilmente testadas.O LINQ permite consultar seus dados de diferentes fontes usando consultas idênticas.Ele permite testar suas consultas em listas de objetos em vez de bancos de dados reais.