Looking through some of our business logic code I've found where some methods are being passed an un-executed IEnumerables as a parameters such as this:
GetDetails(IEnumerable <Entity> item) { // do something with the item }
Now the code works fine as is, but what I'm seeing when I'm in debug is that the parameter is passing a raw query, not a collection of anything. To me this seems a little wrong since you could be hitting the database every time that this IEnumberable is used if the query is pointed at a database.
So what i'm asking, is passing an un-executed IEnumerable as a parameter to a method bad practice?
After more investigation
I've read around more on stackoverflow, and found this particular question where Eric Lippert says:
Remember, a query expression gives you an object which represents the query itself. The object does not represent the RESULTS of the query, the object represents a query. Think of it as a SQL query string, only smarter. You ask the query for its results, and the query executes. You ask it again, the query executes again; no guarantees that the results are the same the second time you ask; the world might have changed since then
To me, this seems to say that if you're going ot use a defered query such as an IEnumberable, to be careful where you use it, and when you use as you might not get the results which are expected. But further into the answers I see that Bevan says he personally does this:
Parameters to methods - use IEnumerable unless there's a need for a more specific interface.
So my question still stands, is passing an un-executed IEnumerable as a parameter to a method bad practice or should I not care about the when the data is requested, just that it is requested.
