ASP.NET MVC Translated for the Web Forms Programmer (5 in a series) - What the Frig is a View Model?

I wanted to expound on something very important that I kind of glazed over in the last post, View Models. View Models are something that is very pivotal to MVC and were one of the hardest things for me to understand. I feel like it's important to go over them in depth so you can understand them as well. 

 

I actually don't love the concept of a View Model, it's a little muddy for me. I understand that it is important because it allows the View to do what it was made for: rendering and displaying elements. However, like any other programmer I like things clean and easily defineable. I like concrete answers, and non-redundant interfaces. A View Model is none of these things. It is an arbitrary collection of data gathered for the express purpose of conveiniently grouping your views. 

 

Before I completely talk you out of them I must clarify that I love using them in my MVC applications because it alows me to seperate my OO archtecture from my Views. You know, seperation of concerns and all that. 

 

So how do I get started?  A View Model is simply a class that you build to aggregate the data you want to display in your view. 

 

Let's say I have a class Car and a class Train. I want a view to display all the ways I can get from New Jersey to New York. I have a train schedule and a list of rental cars. The classes Train and Car are not associated to each other in my data model. So, what to do? That is where our View Model comes in. They are pretty easy to create, my Car/Train view Model is called TransportationViewModel and it looks like this:

 

To populate my View in my Controller I create an action and when I return my View I pass in an instance of my TransportationViewModel. Like this:

 

As you can see this is just a simple class that contains both a list of Cars and a Train. My view will be strongly typed and inherit from this View Model. This is how it will look:

 

As you can see, my View Model allows me to pass my Data to my view and I don't have to muss with my objects or my model. 

 

 When it comes to data manipulation you want to keep that in the Model, not do it in your View Model. Unless what you are messing with is specifically for that particular view. 

 

Now, the question of the year is: "Do I need a new View Model for each View?" The answer is: it's up to you. If you only need one class in your particular view than you don't need one. However, I find that to be very rare.