What do you name the "other" kind of view-model in an MVVM project?

With MVVM, I think of a view-model as a class that provides all the data and commands that a view needs to bind to.

But what happens when I have a database entity object, say a Customer, and I want to build a class that shapes or flattens the Customer class for use in a data grid. For example, maybe this special Customer object would have a property TotalOrders, which is actually calculated using a join with a collection of Order entities.

My question is, what do I call this special Customer class? In other situations, I'd be tempted to call it a CustomerViewModel, but I feel like "overloading" the notion of a view-model like thi开发者_Go百科s would be confusing in an MVVM project. What would you suggest?

I believe you were correct in your original thoughts. The "View Model" classes are those that expose data objects in the domain Model such that these model objects are more easily consumed and managed.

Check out http://en.wikipedia.org/wiki/Model_View_ViewModel

Therefore, the Customer and Order classes are pieces of the "Model". What you describe and were considering calling the CustomerViewModel is indeed a "View Model" and then obviously your WPF page/control is the "View".

In terms of naming it... Go with whatever you like! But I like your original idea of CustomerViewModel. Or perhaps name it a little closer to that of the View. For example, CustomerOrderSummaryViewModel if the page is the CustomerOrderSummary page.

We call ours Data View Models.

For example, we may have Results.xaml that has the Results_ViewModel as the view model. The results page has a grid, where each row in the grid is a Customer. But, like you said, you want a view model for the customer so that you can have a property like 'Total Orders.' In this case, our grid would contain a collection of Customer_DataViewModel.

This comes up quite frequently where is some examples you have a List objects that aren't quite view models. Since you are changing the Customer model object into something more for the VM, you could name it CustomerDto or I agree with the rest of the posters, CustomerViewModel (CustomerVM) is fine too.

I do not like the CustomerDto as it implies another concept (ie. something representing data to be sent elsewhere). We use the term PresentationModel as it is basically 'presenting' an underlying model object with properties that do not belong in the model-layer. For me, I use the term ViewModel for when I can actually change the model and PresentationModel for read-only views.