Trennung von Bedenken mit Linq To SQL und DTOs

Question

Ich habe kürzlich ein neues Webforms-Projekt gestartet und beschlossen, die Geschäftsklassen von allen DBML-Referenzen zu trennen.Meine Business-Layer-Klassen greifen stattdessen auf diskrete Methoden der Datenschicht zu und sind zurückgegebene Sammlungen von DTOs.Die Datenschicht könnte also DTOs wie folgt projizieren:

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

Obwohl das Erstellen der DTO-Objekte mehr Arbeit bedeutet, scheint dies ein besserer Ansatz für eine enge Bindung zwischen Business- und Datenschichten zu sein und bedeutet, dass ich die Business-Schicht testen kann, ohne dass eine Datenbank vorhanden ist.

Meine Frage ist: Ist das eine gute Praxis? Gibt es eine Möglichkeit, die DTOs zu generieren (vielleicht über SQLMetal) und auf welche anderen Probleme könnte ich im Verlauf des Projekts stoßen?

Answer 1

Ich weiß nicht, ob es die beste Vorgehensweise ist, aber ich habe in der jüngeren Vergangenheit ähnlichen Code geschrieben, weil auch ich der Meinung war, dass ich die Trennung von Bedenken verbessern könnte, indem ich in meiner Anwendung meine eigenen Klassen anstelle der vom LINQ-Designer generierten Klassen verwende .

Möglicherweise möchten Sie einfach einen IQueryable<Customer> anstelle eines IList<Customer> von Ihrer Datenzugriffsmethode zurückgeben.Da IQueryable<T> von IEnumerable<T> erbt, sollte der Rest Ihrer App recht gut damit umgehen können.Sie können es auch in eine Liste konvertieren, wenn Sie es wirklich brauchen.

Dies hat den Vorteil, dass Sie Ihre Abfrage ganz einfach dynamisch ändern und die vom SQL Server zurückgegebene Datenmenge minimieren können.

Z.B.Wenn Ihre Methodensignatur iQueryable istu003CCustomer> GetCustomers () Sie können einen einzelnen Kunden erhalten, indem Sie GetCustomers (). WO (C => CASTOMERID == 101) .Single ();

In diesem Beispiel würde nur ein Datensatz aus der Datenbank zurückgegeben, während ich mir derzeit vorstelle, dass Ihr Code entweder alle Kunden zurückgeben würde oder Sie separate Methoden (und damit sehr sich wiederholenden Code) schreiben müssten, um all die verschiedenen Dinge zu berücksichtigen, die Sie möglicherweise wünschen zum Filtern.

Answer 2

Meiner Meinung nach werden DTO-Objekte in den meisten Fällen beim Umgang mit LINQ nicht benötigt.Generierte LINQ-Klassen können einfach getestet werden.LINQ bietet Ihnen die Möglichkeit, Ihre Daten aus verschiedenen Quellen mit identischen Abfragen abzufragen.Es gibt Ihnen die Möglichkeit, Ihre Abfragen anhand von Objektlisten statt anhand echter Datenbanken zu testen.