Filtrage XML et base de données à partir de Silverlight: Dynamic LINQ? Y a-t-il un meilleur moyen?

Question

J'ai une application Silveright qui permet aux utilisateurs de spécifier des filtres sur quelques ensembles différents de données persistantes. Les données persistantes peuvent être XML ou une table de base de données relationnelle. J'utilise nHibernate pour la couche de base de données car j'ai besoin de prendre en charge différentes options de base de données, Postgresql et MySQL au minimum. Les champs de filtre varient en fonction du jeu de données interrogé.

Au moment où le filtre est passé du client Silverlight au serveur sous la forme d'une chaîne et j'utilise la classe Dynamic LINQ sur le serveur pour le convertir en une requête LINQ. Cela fonctionne bien pour le cas XML où toutes les données ont été chargées en mémoire mais je ne suis pas sûr que ce soit la meilleure approche pour la base de données.

Ma question est de savoir si l'envoi du filtre sous forme de chaîne à partir du client, puis l'analyse avec la bibliothèque Dynamic LINQ est la meilleure approche? Serai-je capable d'utiliser les requêtes LINQ générées avec nHibernate? Sinon, devrais-je envisager de sérialiser un objet Expression dans Silverlight et de le transmettre au serveur? Ou y a-t-il un autre moyen?

J'ai besoin de mes objets persistants pour fournir une interface standard pour l'accès et il y en a quelques uns donc ce n'est pas une option pour fournir une interface de méthode différente pour chaque filtre requis. Ci-dessous un exemple de l'interface supportée par mes classes de persistance et le bit avec lequel je me bats est l'expression whereExpression.

public interface ICustomerPersistor 
{ 
    Customer Add(Customer customer); 
    Customer Update(Customer customer); 
    Customer Delete(Customer customer); 
    Customer Get(Guid customerId); 
    int Count(string whereExpression); 
    Customer Get(string username, string password); 
    List<Customer> Get(string whereExpression, int offset, int count); 
} 

Answer 1

Avez-vous considéré ADO.NET Data Services? Cela vous permet d'effectuer des requêtes LINQ sur une API REST (supportée par WCF) - mais l'outillage fait tout le travail lourd ...

Beaucoup (pas tous) les filtres LINQ standards (etc) sont supportés, et peuvent être composé.

En particulier, pour données interrogation, ADO.NET Data Services devrait être bien - pour données updateing vous devez faire plus de travail (ou utiliser une API séparée, non REST pour les mises à jour). J'ai une série de posts on my blog couvrant cela pour LINQ-to-SQL (le travail devrait être similaire pour les autres fournisseurs LINQ).