Linq to SQL utilisant plusieurs DataContexts dans une seule requête

Question

J'ai cette séquence de requête Linq to SQL qui renvoie essentiellement une recherche sur une table appelée PROJECTS. et je profite de l'exécution différée pour la construire lentement.

var query = from p in objDBContext.PROJECTs 
where (p.PROVIDER_ID == cwForm.productForm) 
select p; 

query = from p in query 
where p.SubmittedDate >= cwForm.beginDateForm 
select p; 

j'ai écrit quelques fonctions SQL qui renvoient des valeurs et des valeurs de table scalaire en fonction d'aide, car LINQ ne supporte pas ISDATE() ou recherche en texte intégral. ils sont dans le même fichier .dbml que la table Projects.

Alors maintenant, j'ai:

var dateQuery = from d in objDBContext.ISDATE 
select d; 
//returns a bool 

var ftsQuery = from f in objDBContext.FullTextSearch 
select f; 
//returns a valued-table with the primary keys of hits with fulltextsearch 

Ma question est, comment puis-je utiliser ces nouvelles objDBContexts sur la p requête initiale? Je suis également intéressé à trouver comment mapper un executequery() dans la requête d'origine.

Quelque chose comme:

query = from p in query 
     from d in dateQuery 
     from f in ftsQuery 
where d.ISDATE(p.Field1) && f.FullContextSearch(searchString)  

    select p; 

J'espère que le bon sens. J'ai quelques types incompatibles erreurs et ai essayé googling pendant un moment mais n'ai pu trouver n'importe quoi.

Answer 1

Puisque vous avez défini vos méthodes de la classe de contexte, utilisez la même instance pour les trois:

var query = from p in objDBContext.Projects where 
    p.PROVIDER_ID == cwForm.productForm 
    && objDBContext.ISDATE(p.Field1) 
    && objDBContext.FullTextSearch(searchString) 
     //assuming FullTextSearch returns boolean 
    select p 

si FullTextSearch ne retourne pas booléen, vous devez construire une expression qui fait. Comme si elle renvoyait IList, vous pourriez faire objDBContext.FullTextSearch(searchString).Contains(p)

Gardez à l'esprit ce que vous essayez de faire causera trois allers-retours à la base de données, peu importe la façon dont vous l'avez coupé. Il vaudrait peut-être mieux simplement créer votre SQL dans ce cas. LINQ to SQL ne peut pas et ne doit pas remplacer SQL 100% du temps.