Question

I have a repository class that wraps my LINQ to SQL Data Context. The repository class is a business line class that contains all the data tier logic (and caching and such).

Here’s my v1 of my repo interface.

public interface ILocationRepository
{
    IList<Location> FindAll();
    IList<Location> FindForState(State state);
    IList<Location> FindForPostCode(string postCode);
}

But to handle paging for FindAll, I’m debating whether or not to expose IQueryable<ILocation> instead of IList to simplify the interface for circumstances such as paging.

What are the pros and cons to exposing IQueryable from the data repo?

Any help is very much appreciated.

Answer 1

The pros; composability:

• callers can add filters
• callers can add paging
• callers can add sorting
• etc

The cons; non-testability:

• Your repository is no longer properly unit testable; you can’t rely on a: it working, b: what it does;
  • the caller could add a non-translatable function (i.e. no TSQL mapping; breaks at runtime)
  • the caller could add a filter/sort that makes it perform like a dog
• Since callers expect IQueryable<T> to be composable, it rules out non-composable implementations – or it forces you to write your own query provider for them
• it means you can’t optimize / profile the DAL

For stability, I’ve taken to not exposing IQueryable<T> or Expression<...> on my repositories. This means I know how the repository behaves, and my upper layers can use mocks without worrying “does the actual repository support this?” (forcing integration tests).

I still use IQueryable<T> etc inside the repository – but not over the boundary. I posted some more thoughts on this theme here. It is just as easy to put paging parameters on the repository interface. You can even use extension methods (on the interface) to add optional paging parameters, so that the concrete classes only have 1 method to implement, but there may be 2 or 3 overloads available to the caller.