When should one choose IQueryable or IEnumerable?

First of all: I am sorry for the lack of references in this discussion, I should have saved the links I went through.

Browsing over the WWW I found some interesting articles about those interfaces, and this subject got my atention because I realised that as a low experienced developer I tend to use only IEnumerable. But after reading through, first it seemed like only IQueryable should be used when querying on external sources of data, which makes sense as the Interface applies filters directly on the source instead of bringing all data to memory.

But then, I found this article that said IQueryable should not be used because it would break test-ability and a few other reasons. This got me lost in between both of the interfaces, not knowing which and when to use one them, of course I will research in more depth, but first I would like to hear this lovely community opnion.

So my fellow Dotnet fans, what are your thoughts on this?

Comments

[James Hickey]

IQueryable is specifically when you want to query your database using LINQ. That's pretty much it.

Really, you should never be returning anything with IQueryable but only using existing APIs that expose some IQueryable compatible methods (like EF). And then returning the results as IEnumerable.

[Leonardo Aguiar]

I never return anything to the front-end with IQueryable, if that's what you meaning. But internally, like from a Repository to a Controller, wouldn't it be better to return an IQueryable object?

Suppose my controller calls a repository method to query over a database and return only the objects based on some filter, the repository returns the IQueryable object and then the controller checks if the object is empty, if it is not, it returns the object.ToList(). Would that be better in terms of performance?

[James Hickey]

No, it wouldn't be better performance overall because you still have to "do" the database query in order to check whether there are any rows.

Also, exposing repository methods where you might further "chain" them sounds like a good idea at first (performance, composability, etc.). But it becomes harder to reason about when you are mixing and chaining multiple methods.

Ideally, you should have a repo method that does the one thing you need. If that involves having to do multiple SQL queries then that one method should do them. So performance isn't an issue (actually, it could be better in this scenario) and it's very explicit as to what your code is doing.

E.g. you might have a method called GetUsersForProductXHavingPendingOrders

You could make that into two methods: GetUsersForProductX and GetUsersHavingPendingOrders, but the one combined method is more explicit and under the covers can implement whatever performance "tricks" needed.

In the end, IQueryable is really only for LINQ-to-SQL providers to use.

[Ian Knighton]

A quick pass over the article you linked, I don't think I fully understand what the difference is.

Personally, I've never used IQueryable. With IEnumerable and objects that implement it (List<T> for example) you can just use LINQ to query and manipulate data.

I try to minimize interfaces and dependencies as much as possible. Especially since a lot of my work now is in .Net Core where the framework is still somewhat undefined. The less dependencies you have, the less problems you have to solve if something changes.