XML and Database Filtering from Silverlight: Dynamic LINQ? Is there a better way?

Question

I have a Silveright app that allows users to specify filters on a few different sets of persisted data. The persisted data can be XML or a relational database table. I'm using nHibernate for the database layer as I need to support different database options, Postgresql and MySQL at a minimum. The filter fields vary depending on which data set is being queried.

At the moment the filter is passed from the Silverlight client to the server as a string and I make use of the Dynamic LINQ class on the server to convert it to a LINQ query. That works well for the XML case where all the data has been loaded into memory but I'm not sure whether it's the best approach for the database.

My question is whether sending the filter as a string from the client and then parsing with the Dynamic LINQ library is the best approach? Will I be able to use the LINQ queries generated with nHibernate? Alternatively should I consider serialising an Expression object in Silverlight and pass that to the server? Or is there some other way?

I need my persited objects to provide a standard interface for access and there are a few of them so it's not an option to provide a different method interface for each filter required.

Below is an example of the interface my persistence classes support and the bit I'm struggling with is the 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

Have you considered ADO.NET Data Services? This allows you to perform LINQ queries over a REST API (backed by WCF) - but the tooling does all the heavy lifting...

Many (not all) of the standard LINQ filters (etc) are supported, and can be composed.

In particular, for querying data, ADO.NET Data Services should be fine - for updateing data you need to do more work (or use a separate, non-REST API for updates). I have a series of posts on my blog covering this for LINQ-to-SQL (the work should be similar for other LINQ providers).