Séparer les préoccupations avec Linq To SQL et DTO

Question

J'ai récemment lancé un nouveau projet de formulaires Web et décidé de séparer les classes métier de toutes les références DBML.Mes classes de couche métier accèdent à la place à des méthodes discrètes de couche de données et reçoivent des collections de DTO renvoyées.Ainsi, la couche de données peut projeter des DTO comme suit :

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

Bien que la construction des objets DTO ajoute du travail, cela semble être une meilleure approche pour une liaison étroite entre les couches Business et Data et signifie que je peux tester la couche Business sans la présence d'une base de données.

Ma question est la suivante : est-ce une bonne pratique ? Existe-t-il un moyen de générer les DTO (peut-être via SQLMetal) et quels autres problèmes pourrais-je rencontrer au fur et à mesure que le projet progresse.

Answer 1

Je ne sais pas si c'est la meilleure pratique, mais j'ai écrit du code similaire dans un passé pas si récent parce que moi aussi je pensais que je pouvais améliorer la séparation des préoccupations en utilisant mes propres classes au lieu de celles générées par le concepteur LINQ dans mon application. .

Vous souhaiterez peut-être envisager simplement de renvoyer un IQueryable<Customer> au lieu d'un IList<Customer> à partir de votre méthode d'accès aux données.Puisque IQueryable<T> hérite de IEnumerable<T>, le reste de votre application devrait être capable de le gérer assez bien.Vous pouvez également le convertir en liste lorsque vous en avez vraiment besoin.

L'avantage est que vous pouvez modifier dynamiquement votre requête assez facilement et minimiser la quantité de données renvoyées par SQL Server.

Par exemple.Si votre signature de méthode est iQueryableu003CCustomer> GetCustomers () Vous pouvez obtenir un seul client en appelant getCustomers (). Où (c => c.CustomerId == 101) .Single ();

Dans cet exemple, un seul enregistrement serait renvoyé de la base de données alors que j'imagine qu'actuellement votre code renverrait soit tous les clients, soit vous devrez écrire des méthodes distinctes (et donc un code très répétitif) pour répondre à toutes les différentes choses que vous pourriez souhaiter. pour filtrer.

Answer 2

À mon avis, dans la plupart des cas, les objets DTO ne sont pas nécessaires lorsqu'il s'agit de LINQ.Les classes LINQ générées peuvent être facilement testées.LINQ vous donne la possibilité d'interroger vos données provenant de différentes sources en utilisant des requêtes identiques.Il vous donne la possibilité de tester vos requêtes sur des listes d'objets au lieu d'une base de données réelle.