Linq based generic alternate to Predicate<T>?

Question

I have an interface called ICatalog as shown below where each ICatalog has a name and a method that will return items based on a Predicate<Item> function.

public interface ICatalog
{
     string Name { get; }
     IEnumerable<Item> GetItems(Predicate<Item> predicate);
}

A specific implementation of a catalog may be linked to catalogs in various format such as XML, or a SQL database.

With an XML catalog I end up deserializing the entire XML file into memory, so testing each item with the predicate function does does not add a whole lot more overhead as it's already in memory.

Yet with the SQL implementation I'd rather not retrieve the entire contents of the database into memory, and then filter the items with the predicate function. Instead I'd want to find a way to somehow pass the predicate to the SQL server, or somehow convert it to a SQL query.

This seems like a problem that can be solved with Linq, but I'm pretty new to it. Should my interface return IQueryable instead? I'm not concerned right now with how to actually implement a SQL version of my ICatalog. I just want to make sure my interface will allow for it in the future.

Answer 1

You don't need to go all the way and create an IQueryable implementation

If you declare your GetItems method as:

IEnumerable<IFamily> GetItems(Expression<Predicate<Item>> predicate);

Then your implementing class can inspect the Expression to determine what is being asked.

Have a read of the IQueryable article though, because it explains how to build a expression tree visitor, which you'll need to build a simple version of.

Answer 2

Rob has indicated how you might do this (although a more classic LINQ approach might take Expression<Func<Item,bool>>, and possbily return IQueryable<IFamily>).

The good news is that if you want to use the predicate with LINQ-to-Objects (for your xml scenario) you can then just use:

Predicate<Item> func = predicate.Compile();

or (for the other signature):

Func<Item,bool> func = predicate.Compile();

and you have a delegate (func) to test your objects with.

The problem though, is that this is a nightmare to unit test - you can only really integration test it.

The problem is that you can't reliably mock (with LINQ-to-Objects) anything involving complex data-stores; for example, the following will work fine in your unit tests but won't work "for real" against a database:

var foo = GetItems(x => SomeMagicFunction(x.Name));

static bool SomeMagicFunction(string name) { return name.Length > 3; } // why not

The problem is that only some operations can be translated to TSQL. You get the same problem with IQueryable<T> - for example, EF and LINQ-to-SQL support different operations on a query; even just First() behaves differently (EF demands you explicitly order it first, LINQ-to-SQL doesn't).

So in summary:

• it can work
• but think carefully whether you want to do this; a more classic black box repository / service interface may be more testable