ASP.NET MVC terminology is tripping me up - why 'ViewModel'?

I'm an ASP.NET MVC newbie, but have used many Model-View-Controller frameworks previously.

I recently came across the convention of gathering up the pieces of data that your particular view needs (indeed, it's assigned to the ViewData) into a new class called (NameOfView)ViewModel.

Gathering up this data so that it's associated with the functions provided by the View/Controller interaction strikes me as a helper struct, or even cl开发者_开发技巧osure mechanism (in the 'encapsulates a collection of variables' sense).

So why is it called 'ViewModel', given that it's neither a View or Model?

Does anyone else find the name confusing?

EDIT: What's wrong with just putting properties onto the View so that the Controller can populate them (as in other MVC frameworks)?

In my reading on this topic I've come across a variety of arguments as to why a developer would or would not want to use a ViewModel. Some even argue that a ViewModel should never expose anything more than strings. At this point I am not that extreme in my thinking. I will agree however, that it is not a good idea to expose Domain/Core Objects to the view. After some first hand experience it feels cleaner to remove this dependency.

While I don't agree with everything below Daniel Root makes a pretty good case for a ViewModel:

Most MVC examples show directly using a model class, such as a LINQ-to-SQL or Entity Framework class. The Visual Studio wiring for MVC even steers you into this concept with it's default "Add View" code-generation, which lets you quickly gen up views based on a single model class. However, in real-world-apps you often need more than just a single table's data to build out a page. Some examples get around this by stuffing secondary data into ViewData, but a better way to do this is to create a "roll-up" class to contain properties for everything your view will need. This has the added benefits of being more strongly-typed, supporting intellisense, being testable, and defining exactly what a view needs.

Jeff Handley gives a nice description of the ViewModel pattern which he argues can be used in conjunction with MVC.

Edit
I've recently brought my thinking in line with Jimmy Bogard's regarding view models. After a fair amount of pain with each implementation I've tried having one view model per view creates a much cleaner development experience.

The model is a view-agnostic representation of the data. The view model is a view-specific representation of the data: it's the model as it might appear from a given viewpoint.

Consider a model that consists of raw data points; a histogram view might then have a view model consisting of a set of buckets and totals drawn from that data.

Logically, it's a subset or transformation of the model - it could be generated on-demand with a view-specific function and the model as its only input.

Regarding properties on the view vs. a property bag or custom object... I'm sure someone has strong feelings on this, but personally I don't see the big difference. You're producing a view-specific representation of the model and passing it somehow; the exact mechanism doesn't seem all that important.

Re: why can't the controller populate properties on the view?

Because the view doesn't exist at the time the controller action is executing. The idea behind returning an ActionResult from your action is that something later in the processing pipeline will evaluate the result and determine the best course of action (perhaps rendering a view, or maybe selecting a view to match the request (like special views made for mobile devices)).

I did a view posts on selecting the right kind of model object here: Putting the M in MVC Part I, Part II, Part III.

And yes, the term "ViewModel" term is en vogue right now, but it is in the spirit the original MVC adopters had in mind.

This isn't actually an answer but I highly recommend you watch the MVC2 Basics video by Scott Hanselman. It explains everything, and even though I have done ASP.NET MVC before it made a lot of things clear for me.

Its here: http://channel9.msdn.com/Blogs/matthijs/ASPNET-MVC-2-Basics-Introduction-by-Scott-Hanselman

It's called that because it's a "Model made for a View". I understand why the choice of term is a bit confusing.

It's a helpful approach if you don't want all your data passed to the view as a big hash array. It gives you a strongly-typed class dedicated to the UI, which pollutes neither the core Model or the View. It also allows you to encapsulate UI logic -- views should be kept dumb.