9
votes

Pourquoi l'autre parseur LINQ de l'entitéFramework traite-t-il différemment d'un prédicat défini de manière externe?

J'utilise le cadre d'entité de Microsoft en tant qu'indem et je me demande comment résoudre le problème suivant. Je veux obtenir un certain nombre de code> objet code> à partir de la collection code> Produits code> où le produit .Startdate code> est supérieur à aujourd'hui. (Il s'agit d'une version simplifiée de tout le problème.)

I Utilisez actuellement: p> xxx pré>

lorsque ceci est exécuté, après avoir utilisé Tolist () Code > Par exemple, sur la requête, cela fonctionne et le SQL créé est efficacement: p> xxx pré>

Cependant, je veux déplacer le prédicat à une fonction pour une meilleure maintenabilité, alors j'ai essayé ceci: P>

SELECT * FROM Product;


0 commentaires

3 Réponses :


8
votes

Vous devez utiliser un Expression > Pour que cela fonctionne comme si vous avez l'intention. Un clair FUNC indique à Linq que vous souhaitez qu'il exécute le dans MSIL dans votre programme, pas dans SQL. C'est pourquoi le SQL tire dans toute la table, alors votre code .NET exécute le prédicat sur la table entière.


0 commentaires

2
votes

Comme dans le deuxième cas, le filtre FUNC peut-être arbitraire LINQ to EF ne peut pas analyser votre filtre à SQL et doit le résoudre sur le côté du client.


1 commentaires

D'accord, mais cela ne peut pas être toute la réponse car l'expression dans le premier exemple pourrait être quelque chose aussi. Si la fonction GetFilter a été examinée en même temps que le prédicat en ligne, il n'y aurait pas de problème. Cela signifie-t-il que l'ordre d'exécution est différent?



4
votes

Vous retournez un Func , mais pour injecter le prédicat dans le SQL, Linq nécessite un arbre d'expression. Il devrait fonctionner si vous modifiez le type de retour de votre méthode (et de votre variable locale, bien sûr) à Expression > .


0 commentaires