código de proyección repetida en Entity Framework

Question

estoy tratando de resolver un problema similar al que se describe aquí

Initializing strongly typed objects in LINQ to Entities

sólo de totalmente la dirección opuesta. Tengo varias funciones en mi repositorio, todas las cuales devuelven datos con formas idénticas. El problema es mi código de proyección:

select new pocoClass 
{ 
    // complex projection that is several pages long includes grabbing a graph of data 
} 

en el momento en que existe para cada consulta en el repositorio. Intenté moverlo a un inicializador de objetos, pero eso me da el temido "Solo los constructores y los inicializadores sin parámetros son compatibles con LINQ to Entities". problema.

Yo probé la división en dos consultas

var candidates = (from thing in _entities.whatever 
    where (complex.stuff==true) 
    select thing); 

var final = (from thing in candidates.AsEnumerable() 
    let x = thing.ITEMS.Where(blah=>blah.blah==param) 
    let y = x.OTHERITEMS.FirstOrDefault() 
    select new pocoClass(thing,x,y); 

pero aquí final es siempre nula y el código de nuevo pocoClass nunca es llamado. He incluido el let x & y en el anterior porque estos siempre varían entre cada uso de la proyección.

Entonces, ¿tengo que volver a varias copias de mi proyección o hay otra manera de salir de esto?

Answer 1

No estoy seguro si esto es útil para usted, pero lo que a menudo hago es crear métodos de proyección que toman un IQueryable y devuelven un IQueryable para traducir de un objeto de dominio a un DTO. Se parecen mucho a esto:

public static IQueryable<CustomerDTO> ToCustomerDTO(
    IQueryable<Customer> customers) 
{ 
    return 
     from customer in customers 
     select new CustomerDTO() 
     { 
      ... 
     }; 
} 

Esto me permite tener esta proyección en un solo lugar. Desde varios lugares en mi capa de negocios llamo a tal método.

Hay algunas cosas a tener en cuenta, sin embargo:

• asegurarse de que estos métodos de proyección no contienen ninguna lógica de negocio. Tener filtros de casos de uso específicos sería malo.
• A veces tiene un DTO que contiene un gráfico de objeto complejo que desea extraer de manera eficiente de la base de datos en una sola consulta. Con un poco de creatividad, esto a menudo es posible, pero no al devolver un IQueryable. En ese caso, devuelvo una matriz de DTO.
• Coloco esos métodos de proyección como métodos estáticos dentro de la clase DTO. Si bien este no es un diseño muy limpio, descubrió que hace que el código sea muy fácil de mantener.

Espero que esto ayude.