There are times when doing a ToList() on your linq queries can be important to ensure your queries execute at the time and in the order that you expect them to. Those scenarios are however rare and nothing one should worry too much about until they genuinely run into them.

Long story short, use IEnumerable anytime you only need iteration, use IList when you need to index directly and need a dynamically sized array (if you need indexing on a fixed size array then just use a standard array).

As for the execution time thing, you can always use a list as an IEnumerable variable, so feel free to return an IEnumerable by doing a .ToList();, or pass in a parameter as an IEnumerable by executing .ToList() on the IEnumerable to force execution right then and there. Just be careful that anytime you force execution with .ToList() you don’t hang on to the IEnumerable variable which you just did that to and execute it again, or else you’ll end up doubling the iterations in your LINQ query unnecessarily.

In regards to MVC, there is really nothing special to note here. It’s going to follow the same execution time rules as the rest of .NET, I think you might have someone who was bit by confusion caused by the delayed execution semantics in the past and blamed it on MVC telling you this is somehow related, but it’s not. The delayed execution semantics confuse everybody at first (and even for a good while afterwards; they can be a touch tricky). Again though, just don’t worry about it until you really care about ensuring a LINQ query doesn’t get executed twice or require it executed in a certain order relative to other code, at which point assign your variable to itself.ToList() to force execution and you’ll be fine.

There are two issues.

IENumerable<Data> query = MyQuery();

//Later
foreach (Data item in query) {
  //Process data
}

By the time the “Process Data” loop is reached, the query may no longer by valid. For example, if the query is being run on a DataContext that has already been Disposed, your code will throw an exception. This kind of thing becomes very confusing when you are processing a query in a different context than where you created it.

A secondary issue is that your connection will not be released until the “Process Data” loop completes. This is only a problem if “Process Data” is complex. This is mentioned at http://msdn.microsoft.com/en-us/library/bb386929.aspx :

Q. How long does my database connection remain open?

A. A connection typically remains open until you consume the query
results. If you expect to take time to process all the results and are
not opposed to caching the results, apply ToList to the query. In
common scenarios where each object is processed only one time, the
streaming model is superior in both DataReader and LINQ to SQL.

So, these issues are why you are being encouraged to ensure that the query is actually executed, e.g. by calling ToList(). However, as Jimmy Suggests there is nothing stopping you from returning your List as an IEnumerable .

As a general rule, I recommend avoiding iterating over an IEnumerable more than once. Assuming consumers of your code follow this rule, I don’t consider it a concern that someone might hit the database twice by executing the query twice.

Another benefit of enumerating the IEnumerable early is exceptions will be thrown at the appropriate location. This assists debugging.

For example, if you got a deadlock exception inside one of your Razor views, it wouldn’t really be as clear as if the exception occurred during one of your data access methods.