12

J'ai appris à propos de IQueryable et du chargement paresseux/exécution différée des requêtes.Expose IQueryable sur le service WCF

Est-il possible d'exposer cette fonctionnalité sur WCF? Je voudrais exposer un service LINQ-to-SQL qui renvoie un IQueryable sur lequel je peux ensuite effectuer des requêtes supplémentaires sur le client, et enfin exécuter en utilisant un .ToList(). Le format OData est-il applicable dans ce contexte?

Si possible, quel est le terme de cette technique et quels sont les bons tutoriels que je peux suivre? Je vous remercie.

+0

Pour Silverlight, vous pouvez utiliser les services WCF RIA – RichardOD

Répondre

11

Vous devriez vérifier WCF Data Services qui vous permettra de définir la requête Linq sur le client. Les services de données WCF sont probablement la seule solution pour vos besoins.

IQueryable est toujours l'interface et la fonctionnalité dépend du type implémentant l'interface. Vous ne pouvez pas exposer directement les requêtes Linq-To-Sql ou Linq-To-Entities. Il existe plusieurs raisons, telles que les contextes de vie courte ou la sérialisation, qui exécuteront la requête afin que le client obtienne la liste de tous les objets au lieu de la requête.

+0

Merci, c'est ce que je cherchais. – Trust

1

pour autant que je sache, le datacontext n'est pas sens sérialisable que vous ne pouvez pas passer autour avec WCF

1

Vous pouvez utiliser http://interlinq.codeplex.com/ qui vous permet d'envoyer une requête Linq sur WCF.

Les services de données WCF ne peuvent être utilisés qu'avec webHttpBinding et toutes les requêtes Linq ne peuvent pas être exprimées. requêtes lorsque l'écriture WCF Data Service est utilisé est pas si attrayante - nécessite des expressions de chaîne tels que:

.AddQueryOption("$filter", "Id eq 100"); 
0

J'ai été aux prises avec la même question, et se rendit compte qu'une question bien formé est un problème résolu. IQueryable sert essentiellement à filtrer la requête avant de l'envoyer à votre appel de base de données. Ainsi, au lieu d'obtenir 1000 enregistrements et de n'en filtrer que 10, vous obtenez ces 10 premiers éléments. Ce filtrage appartient à votre couche de service, mais si vous créez une API, je suppose que vous la mappez avec les paramètres AND/OR de votre URL.

http: // {hôte}/{entité}/q? Name = john & age = 21.

Alors vous vous retrouvez avec quelque chose comme ceci:

Filter:Column1=Value1 > http://{host}/{entity}q?column1=value1 > SELECT * 
                    FROM Entity 
                    WHERE Column1=Value1 

MVC     > WCF         > DB 

Vous pouvez trouver un très bon exemple [here]

Enfin, depuis votre charge utile de la WCF sera très probablement un JSON, vous peut (et devrait) ensuite les désérialiser dans vos modèles de domaine à l'intérieur d'une collection. C'est jusqu'à ce moment où la pagination devrait se produire, donc je recommanderais une mise en cache WCF (et depuis son HTTP, c'est vraiment simple). Vous utiliserez toujours LINQ côté WebApp, sans clause LINQ "WHERE" (à moins que vous ne souhaitiez créer dynamiquement l'URL exprimée ci-dessus?)

Pour une requête OU complexe, vous devez vous retrouver avec plusieurs WCF requêtes (1 par "ET"), puis les concaténer tous ensemble

-1

S'il est possible d'envoyer IQuerable <> sur WCF, ce n'est pas une bonne chose en matière de sécurité, puisque IQuerable <> pourrait exposer des choses comme la chaîne de connexion à la base de données . Certains des commentaires précédents semblent prometteurs.

+0

"Ce n'est pas une bonne chose en matière de sécurité" ... cela ne dépend-il pas de la façon dont 'IQueryable' est implémenté? – Crono

1

https://remotelinq.codeplex.com/ est un autre choix. Mais il fonctionne dans AppDomain pour analyser les assemblages en cours et les sérialiser. Cette technologie ne convient pas à WinRT car aucun domaine pour WinRT App