Let\'s say i have the following model which is obtained via Entity Framework:
public class User{
public string Name {get;set;}
public int Id {get;set;}
}
<
This could lead to performance problems, but it doesn't necessarily always lead to them.
If you pass an IEnumerable
to the view then the view doesn't necessarily know anything about the backing data source. There could be an unspoken assumption that the consuming code (the view) will enumerate the collection only once. If the collection is enumerated more than once, it's possible that the backing data store would be queried more than once.
Note that this doesn't necessarily mean hitting a database multiple times, but enumerating a collection could come with all sorts of hidden "gotchas".
Passing an IList
to the view is a little more explicit in this regard. The semantic difference between the two interfaces is that the IList
is a complete list, not just a vague enumeration. It's expected to support being queried and enumerated as many times as necessary without performance loss. (There's of course no guarantee that the implementing type provides this, but it's expected to.)
It's not really a question of "deferred execution". The query is going to execute server-side at very close to the same time, whether it's in the controller or in the view. It's not being deferred for very long. It's just a question of how that enumeration is going to be treated by the consuming code.
My new boss is telling me that doing it this way is not MVC conform and the performance will be very bad.
Your new boss really should explain things better. This has nothing to do with MVC and everything to do with IEnumerable
vs. IList
and how LINQ is expected to behave. The same is true in any application which uses those technologies. The fact that you're passing a model from a controller to a view makes this MVC, nothing more. And the performance might be bad, if you're not aware of why it could be. However, there is only ever one true way to know about performance... by measuring it.