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.
Similar Posts
- ASP.NET MVC Translated for the Web Forms Programmer (3 in a series)
- ASP.NET MVC Translated for the Web Forms Programmer (4 in a series)
- ASP.NET MVC Translated for the Web Forms Programmer (1 in a series)
Comments
Javier Lozano on on 10.28.2009 at 9:30 AM
Hi Sara,
Great write up! I like the humor you injected through out, made it a fun read! :)
I wanted to comment on this piece,
"It is an arbitrary collection of data gathered for the express purpose of conveiniently grouping your views."
This is partially true; At times, more often than not, you don't need all the data from your model within your view. A ViewModel is nothing more than a subset snapshot of your data that doesn't have all the "extra pieces" from your domain model.
For example, in your sample you use the Car/Train models within your view. Say that you're using the ActiveRecord pattern for persisnce and that your objects have the .Delete() method on them. Since these are available in the view, nothign stops a developer from calling them. So now you've exposed functionality into a different concern of your application and set yourself up for possible side effects.
karl on on 10.28.2009 at 9:31 AM
Nice post. The spark equivalent of that template look something like:
<viewdata mode="Transportation.ViewModels.TransportationViewModel" />
<set title="List Vehicles" />
<h2>List Vehicles</h2>
<h4>Cars:</h4>
<for each="var c in Model.Cars">
Make: <b>${c.Make}</b>
Model: <b>${c.Model}</b>
</for>
<h4>Train:</h4>
<b>${Model.Train.Line}</b>
<b>${Model.Train.Schedule}</b>
Even for a simple example, there's less noise, and I've
added html encoding to prevent possible injection attacks.
Eric Williams on on 10.31.2009 at 1:53 AM
I think that yet another way to think about the view model is you literally say the phrase 'presentation model'. Such that if you have a complicated domain model that has a deep object graph you will see very quickly how cumbersome that can be to work with in your views. Having a view model which flattens that domain model will make that easier to work with. You are modeling for your presentation layer.
Just my two cents...
Dmitry on on 10.31.2009 at 11:20 PM
You probably want to HtmlEncode model data in the view.
compare internet casinos on on 1.14.2010 at 10:42 PM
I am finding it to pass a textbox value from the view to the controller and I want that textbox value to referred there on the controller. How to do this? Help me
car parts ware house on on 1.20.2010 at 2:58 AM
Thanks for great tutorial :)