Mark Seemann suggests in his article “IQueryable is Tight Coupling” that designing an API such that it exposes an IQueryable<T> interface is a bad idea for several reasons.
Why?
..the IQueryable<T> interface is one of the best examples of a Header Interface that .NET has to offer. It's almost impossible to fully implement it.
This simple fact means that you can never be sure that the method will return a complete implementation of the IQueryable interface.
Even so, the interface is so flexible and expressive that with a single exception, it's always possible to write a query that a given provider can't translate.
The only implementation that fully implements IQueryable<T> is the in-memory implementation
According to Mark, this makes the abstraction leaky because more often than not, the IQueryable will be implemented by a Store provider inside your code.
While the argument makes perfect sense, a counter point could be, how bad is the leaky abstraction? Does it make writing code at least somewhat simpler that we can bear to live with it?
For instance, ASP.NET Web API magic makes it easier to use the same webapi for filtered data through request parameters, if the return type is an IQueryable. Similarly we have WCF RIA Services where the DomainContext methods returning IQueryable can used by the client to fetch only required data by using filter descriptors right in the XAML or from your JQuery Client.
What do our readers think? Do the benefits of the flexibility outweigh the leakiness?