2009-11-27 4 views
1

est-il possible d'ajouter une méthode d'extension à IQueryable<T> puis, pour mes Linq2Sql ou EF ou NHibernate ou LinqToObjects, définir sa fonctionnalité/comment chaque référentiel va implémenter cette méthode/traduire cette méthode à quelques sql?Puis-je faire cela avec un IQueryable <T>?

Par exemple, imaginez que je veux ce qui suit: -

var result = (from q in db.Categories() 
       where q.IWishIKnewHowToCode("hi") 
       select q).ToList(); 

maintenant, le code de la méthode d'extension IWishIKnewHowToCode() sera différent quand il est L2S, par rapport à EF ou LinqToObjects, etc.

I » Je ne parle pas de tuyaux et de filtres, ici. Que je sais comment faire ça. Imaginez donc que si c'était L2S, cette méthode ferait une clause linq Where mais si le référentiel était ... disons ... LinqToObjects, il ferait Take(10).

Est-ce possible?

(Je ne suis pas sûr de ce qu'il est officiellement appelé ... ce que je suis désireux de le faire)

+1

Je ne sais pas pourquoi vous voulez créer une extension pour IQueryable . Dans votre exemple, il semble que vous souhaitiez créer une méthode d'extension pour le type T. Et vous pouvez créer une surcharge pour chaque type T. Ai-je raté quelque chose? – DSO

+0

Oui, il te manque quelque chose ici. Le type est une classe POCO. Il ne sait rien d'une persistance/référentiels. IQueriable peut connaître la persistance/les référentiels dans chaque projet/couche du référentiel. En tant que tel, j'espère générer une expression Queryable .. et chaque projet de persistance devra expliquer comment implémenter cette méthode d'extension (mot-clé), par rapport à son référentiel dépendant. Par exemple. Si le mot-clé est 'IWishIKnewHowToCode' ... alors pour un dépôt L2S contre le serveur sql, il s'agira d'une clause where. –

Répondre

1

qui est assez mal, mais le plus proche je pense serait-cas particulier le fournisseur :

public static class Test 
{ 
    public static IQueryable<T> IWishIKnewHowToToCode<T>(
     this IQueryable<T> data, string something) 
     // perhaps "where T : SomeBaseTypeOrInterfaceForThePredicate" 
    { 
     switch (data.Provider.GetType().Name) 
     { 
      case "Foo": return data.Take(10); 
      case "Bar": return data.Where(somePredicate); 
      default: return data; 
     } 
    } 
} 

(évidemment il y a d'autres façons de mettre sur Type).

Ensuite, utilisez la syntaxe par courant (pas interroger la syntaxe):

var result = db.Categories().IWishIKnewHowToCode("hi").ToList(); 
+0

J'espérais ne pas avoir le fournisseur à connu à ce niveau, mais implanté seulement à l'intérieur de chaque espace de noms de fournisseurs. Basiquement, cette méthode d'extension serait * persistance ignorante * et chaque persister/référentiel impliquerait alors la logique, comment elle voit l'ajustement. (mes exemples Take/Where où les exemples extream, utilisés ci-dessus .. par conception). Est-ce que ça a du sens, Marc? (et merci beaucoup de lire ma question). –

+0

Marc aussi, j'ai trouvé cet article de blog intéressant et pertinent à cette question: http://marcgravell.blogspot.com/2009/02/pragmatic-linq.html. En ce qui concerne ce post, je * pense * que j'essaie de générer ma propre expression qui va générer son propre SQL? (J'espère avoir utilisé la bonne terminologie, ici). –

+0

Je ne pense pas que ce soit possible (de manière générique). LINQ-to-SQL vous permet d'exécuter TSQL personnalisé, mais pas dans le cadre d'une expression. EF vous permet d'émettre des ESQL personnalisés (une syntaxe différente), et non AFAIK dans le cadre d'une 'Expression'. –

Questions connexes