Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
In my ASP.net MVC4 web application I use IEnumerables, trying to follow the mantra to program to the interface, not the implementation.
Return IEnumerable(Of Student)
vs
Return New List(Of Student)
People are telling me to use List and not IEnumerable, because lists force the query to be executed and IEumerable does not.
Is this really best practice? Is there any alternative? I feel strange using concrete objects where an interface could be used. Is my strange feeling justified?
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.
List--passing around a List implies that the contents of the list are going to be modified. If you want to return a collection, use IReadOnlyCollection. List is for use within methods, and for exchange between methods that modify the list. That's it!
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.
IEnumerable that can throw is probably making a mistake. Deferred IEnumerable methods should be split into two: one non-deferred method checks parameters and sets up, throwing if necessary (say, because of a null argument). Then it returns a call to the private implementation which is deferred. I don't think my comments are completely at odds with your answer, but do think that you've left out an important aspect in your answer, which is the semantic meaning of using IEnumerable vs. a List (mutation) vs. IReadOnlyCollection (no benefit to deferral).