Teniendo en cuenta LINQ to Entities no es compatible con "Métodos personalizados", ¿cómo te quedas seco?

Question

se han topado con este problema:

Custom Methods & Extension Methods cannot be translated into a store expression

Básicamente tengo algunas consultas LINQ complicados, por lo que quería descomponerlas en sub consultas que se implementan como métodos que devuelven IQueryables. Mi esperanza era que estas IQueryables pudieran componerse juntas en una declaración LINQ (como estoy seguro de que puedes hacer en LINQ to SQL).

El problema es que si se intenta esto se obtiene (por ejemplo):

LINQ a Entidades no reconoce el método 'System.Linq.IQueryable`1 [hilo] GetThreadsByMostReccentlyPosted (Int32) ' método, y este método no puede ser traducido a una expresión de tienda.

Me parece muy importante que si usa un LINQ ORM, entonces deba ser capaz de redactar consultas LINQ. De lo contrario, cualquier lógica de consulta común debe copiarse & pegada.

Dada esta limitación, ¿cómo se supone que debo permanecer SECO con LINQ para Entidades?

Answer 1

dos maneras:

1. métodos que devuelvan expresiones se pueden utilizar
2. separar el consultables y los bits enumerables

Para # 1, tenga en cuenta:

public Expression<Func<Foo, bool>> WhereCreatorIsAdministrator() 
{ 
    return f => f.Creator.UserName.Equals("Administrator", StringComparison.OrdinalIgnoreCase); 
} 

public void DoStuff() 
{ 
    var exp = WhereCreatorIsAdministrator(); 
    using (var c = new MyEntities()) 
    { 
     var q = c.Foos.Where(exp); // supported in L2E 
     // do stuff 
    } 
} 

Para una ejemplo del número 2, lea este artículo: How to compose L2O and L2E queries. Considere el ejemplo dado allí:

var partialFilter = from p in ctx.People 
        where p.Address.City == “Sammamish” 
        select p; 

var possibleBuyers = from p in partiallyFilter.AsEnumerable() 
        where InMarketForAHouse(p); 
        select p; 

Esto podría ser menos eficiente, o puede estar bien. Depende de lo que estés haciendo. Por lo general, está bien para las proyecciones, a menudo no está bien para las restricciones.

Actualización Acabo de ver an even better explanation of option #1 de Damien Guard.

Answer 2

EF no puede redactar una consulta a partir de una expresión LINQ que incluya un método. EF necesita valores literales para componer el SQL.

Tendrá que conformarse con consultas "comunes" que devuelven un superconjunto de las entidades que necesita para un caso determinado, luego utilice métodos de extensión y LINQ para restringir el conjunto de resultados una vez que se ha devuelto desde la base de datos.