ASP.NET MVC - Linq to Entities model as the ViewModel - is this good practice? [closed]

Question

Quick questions really.

I am currently building a site using asp.net MVC and the entity framework. I have a couple of repositories in place which return entities or lists of entities. I am finding that in the majority of my pages I'm having to pull data from a variety of related tables. This is ok so long as I load up the related entities using 'include' in my queries - but is this good practice?

Would it be better to create a custom viewmodel object that contains just the bits of info I need, or is there nothing 'wrong' with pulling an object graph that is perhaps 5 - 6 tables deep just to display what you need to in your view?

Apologies if this question doesn't make too much sense. I may have fundamentally misunderstood how a model should be used here :)

Thanks

Answer 1

I would suggest reviewing the rendering code in your views and the posting code in your controllers. Are they made overly complex by the approach you are taking? If not you're probably ok to keep things as they are. If the view and controller code would be greatly simplified by introducing a custom view model then consider creating one. Custom view models essentially abstract some of that complexity that is probably getting handled somewhere else at the moment.

Answer 2

If your views start doing things like

<% foreach (var order in Model.Orders.Any(x => x.Products.Any(p => p.Category == "xx")) %>

then you definitely need ViewModel. You can go with

ViewData["flattened_orders"]

if you prefer magic strings, but I doubt so.

Then, there's a question of presentation attributes needed on your entities, then you need to expose all properties on them so that model binder can work... then you need additional presentation-only information like list of countries...

So, for simple applications, you may skip ViewModel. But for simple applications you can do Response.Write and manual SQL, anyway ;-)

I actually like this post about similar issue. The approach represented there might seem too "academic" at first, but it is from real projects, and the more I do ASP.NET MVC, the more I like it and get closer to it.