Rules of thumb for when to call ToList when returning LINQ results

Return ToList if:

• You don't want or care for lazy query evaluation.

Edit:

Also, return ToList if:

• You are using some kind of Linq to SQL framework (LLBLGen, EF, etc.), and you need to do an operation on the list that cannot be translated into SQL by the framework.

First off, you should NEVER have side effects in a query. That is a worst practice. Queries should answer a question, not produce an effect.

The answer to your question is: return a query when the caller expects a query; return a list when the caller expects a list. When you design your method, decide what the caller is more likely to want, implement that, and then document it.

When considering whether the caller wants a query or a list, think about the differences between queries and lists:

• queries are always up-to-date. If the objects/databases/whatever that the query queries against changes its content, then the query results will change if you run the query again. Lists don't change their contents and therefore lists get out of date. If your caller requires the latest data then give them a query. If they require a snapshot of the data that they can inspect at leisure then give them a list.

• queries are potentially expensive to execute to obtain their results. Lists are cheap to obtain their results. If the caller is likely to want to interrogate the result many times and expects to get the same results each time then give them a list.

• Constructing a query is fast. Executing a query to construct a list is slow. A list always obtains all the results of a query. The caller might want to further restrict the query, by, say, taking only the first ten elements. If the caller does not want or need to take on the expense of fully iterating over the entire query then give them a query; don't make that decision on their behalf and give them a list.

• queries are tiny. Lists are big. Many queries can be iterated over n items in O(1) space; a list with n items takes up O(n) space. If the result set is enormous then putting it in a list is probably inefficient.

• and so on.

There is no easy answer. The answer is the same as the answer to any other design problem: Consider all the pros and cons of each possible solution in the context of what is most likely wanted by the user of the feature, and then pick a reasonable compromise solution.