IEnumerable vs IQueryable for Business Logic or DAL return Types

Question

I know these questions have been asked before, I\'ll start by listing a few of them (the ones I\'ve read so far):

• IEnumerable vs IQueryable
• List, ILis

Answer 1

1. well, you aren't strictly coupled to any specific provider, but as a re-phrasing of that: you can't easily test the code, since each provider has different supported features (meaning: what works for one might not work for another - even something like .Single())
2. I don't think so, if there is any question in your mind about ever changing provider - see above
3. it just provides a decorated wrapper that uses .Compile() on any lambdas, and uses LINQ-to-Objects instead. Note LINQ-to-Objects has more support than any other provider, so this won't be an issue - except that it means that any "mocks" using this approach don't really test your actual code at all and are largely pointless (IMO)
4. yeah, tricky - see below
5. yeah, tricky - see below

Personally, I'd prefer well defined APIs here that take known parameters and return a loaded List<T> or IList<T> (or similar) of results; this gives you a testable/mockable API, and doesn't leave you at the mercy of deferred execution (closed connection hell, etc). It also means that any differences between providers is handled internally to the implementation of your data layer. It also makes a much closer fit for calling scenarios such as web-services, etc.

In short; given a choice between IEnumerable<T> and IQueryable<T>, I choose neither - opting instead to use IList<T> or List<T>. If I need additional filtering, then either:

1. I'll add that to the existing API via parameters, and do the filtering inside my data layer
2. I'll accept that oversized data is coming back, which I then need to filter out at the caller