Separando preocupaciones con Linq To SQL y DTO

Question

Recientemente comencé un nuevo proyecto de formularios web y decidí separar las clases comerciales de cualquier referencia a DBML.En cambio, mis clases de capa empresarial acceden a métodos de capa de datos discretos y se devuelven colecciones de DTO.Entonces, la capa de datos podría proyectar DTO como el siguiente:

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

Aunque la creación de objetos DTO agrega trabajo, esto parece un mejor enfoque para un vínculo estrecho entre las capas de Negocio y Datos y significa que puedo probar la capa de Negocio sin que haya una base de datos presente.

Mi pregunta es, ¿es esta una buena práctica? ¿Existe alguna forma de generar DTO (tal vez a través de SQLMetal) y qué otros problemas podría encontrar a medida que avanza el proyecto?

Answer 1

No sé si es una buena práctica, pero escribí un código similar en un pasado no tan reciente porque también sentí que podía mejorar la separación de preocupaciones usando mis propias clases en lugar de las generadas por el diseñador LINQ dentro de mi aplicación. .

Es posible que desee considerar simplemente devolver un IQueryable<Customer> en lugar de un IList<Customer> desde su método de acceso a datos.Dado que IQueryable<T> hereda de IEnumerable<T>, el resto de su aplicación debería poder manejarlo bastante bien.También puedes convertirlo en una Lista cuando realmente lo necesites.

La ventaja de esto es que puede modificar dinámicamente su consulta con bastante facilidad y minimizar la cantidad de datos devueltos por SQL Server.

P.ej.Si su firma de método es IQUERABLEu003CCustomer> GetCustomers () puede obtener un solo cliente llamando a getCustomers (). Donde (c => c.customerid == 101) .single ();

En este ejemplo, solo se devolvería un registro de la base de datos, mientras que imagino que actualmente su código devolvería todos los clientes o se le pediría que escriba métodos separados (y, por lo tanto, un código muy repetitivo) para atender todas las diferentes cosas que pueda desear. para filtrar.

Answer 2

En mi opinión, en la mayoría de los casos los objetos DTO no son necesarios cuando se trata de LINQ.Las clases LINQ generadas se pueden probar fácilmente.LINQ le brinda la posibilidad de consultar sus datos de diferentes fuentes utilizando consultas idénticas.Le brinda la posibilidad de probar sus consultas con listas de objetos en lugar de bases de datos reales.