J'ai une requête de Linq qui ressemble à ceci comme suit:
var query = from x in table where SomeFunctionReturnsBool() select x;
private Expression<Func<EligibilityTempTable, bool>> SomeFunctionReturnsBool
{
return (x) => true;
}
5 Réponses :
Vous pouvez le faire dans LINQ-TO-SQL en créant un UDF mappé sur le contexte de données; Cela implique d'écrire TSQL et d'utiliser ctx.somefuncerblah (...).
L'alternative est de travailler avec des arbres d'expression - par exemple, cela pourrait être: et utilisez ajouté dodgy . Où (quelquefuncunc ()) - est-ce assez proche? Vous ne pouvez pas utiliser la syntaxe de la requête dans ce cas, mais elle obtient le travail ...
où méthode pour montrer comment vous pourrait Utilisez-le dans la syntaxe de requête. Je
Wow, cool Marc, je ne savais pas à ce sujet. Vérifiez ma réponse ci-dessous ... c'est utile, mais c'est très cool. Merci
Juste pour clarifier, Marc. Si j'utilise l'arbre d'expression comme si vous l'avez ici, je dois utiliser la syntaxe Lambda et non la syntaxe de la requête?
n'utilisez pas la syntaxe de requête pour cela.
var query = table.Where( x => SomeFunction(x) );
Cela ne vous aidera pas avec Linq-to-SQL; Il n'y a toujours pas de traduction de de fonctionnement .
Oui, il n'y a pas de différence entre cela et la syntaxe de la requête
Je voudrais simplement les briser comme si: Vous pouvez créer des fonctions qui passent autour des arbres d'expression.
Fondamentalement, "hors de la boîte", vous ne pouvez pas avoir des requêtes exécutées LINQ-TO-SQL qui ont des fonctions personnalisées. En fait, seules certaines méthodes natales pouvant être traduites en SQL peuvent être utilisées.
Le moyen le plus simple de cela peut malheureusement affecter les performances en fonction de la quantité de données que vous retirez de la DB.
essentiellement , vous ne pouvez utiliser que des fonctions personnalisées dans les cas où les données sont déjà chargées dans la mémoire, c'est-à-dire que SQL a déjà exécuté.
La solution la plus rapide de votre exemple ressemblerait à ceci: < Pré> xxx
Notez la Tolist (). Il exécute le SQL et met les données en mémoire. Vous pouvez maintenant faire ce que vous voulez dans la déclaration / méthode.
Vrai ... Mais vous retirez ensuite tous les enregistrements d'un filtrage en mémoire par rapport au serveur de base de données.
D'accord (avec J.13.L) - Utiliser Tolist () est généralement un mauvais moyen de le faire et fonctionne uniquement avec de petits volumes de données.
Aimerait éviter de tirer tout ce dos. Beaucoup de données. Merci
D'accord, c'est certainement un dernier recours, pour les petits jeux de données, mais bon à savoir! ;-)
Un autre moyen est d'utiliser Expression var results = table.Where(SomeFunctionReturnsBool())
.OrderBy(yt => yt.YourProperty)
//.Skip(pageCount * pageSize) //Just showing how you can easily comment out parts...
//.Take(pageSize)
.ToList(); //Finally executes the query...
private Expression<Func<YourType, boo>> SomeFunctionReturnsBool()
{
return (YourType yt) => yt.YourProperty.StartsWith("a")
&& yt.YourOtherProperty == true;
}
Pour une raison quelconque, cela fait que cela provoque l'exemple d'erreur avec "Impossible de résoudre la méthode où (Expression Lambda)"
Répondit au commentaire, montrant une manière (douteuse) d'utiliser cette approche avec la syntaxe de requête.