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?
Top comments (4)
IQueryableis specifically when you want to query your database using LINQ. That's pretty much it.Really, you should never be returning anything with
IQueryablebut only using existing APIs that expose someIQueryablecompatible methods (like EF). And then returning the results asIEnumerable.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 anIQueryableobject?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
IQueryableobject and then the controller checks if the object is empty, if it is not, it returns theobject.ToList(). Would that be better in terms of performance?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
GetUsersForProductXHavingPendingOrdersYou could make that into two methods:
GetUsersForProductXandGetUsersHavingPendingOrders, but the one combined method is more explicit and under the covers can implement whatever performance "tricks" needed.In the end,
IQueryableis really only for LINQ-to-SQL providers to use.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. WithIEnumerableand objects that implement it (List<T>for example) you can just useLINQto 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.