Model-View-ViewModel and naming conventions for bound data objects in lists (ViewItems)

The problem

When designing Views and ViewModels for M-V-VM (or Presentation Model if you prefer) I often find myself in a situation where I need a ListView or ListBox in the View which is bound to a list of objects exposed from the ViewModel. For several reasons I don’t want to put the domain/business object directly in that list. They may not have all properties I want to display because some extra properties would be calculated for screen only use or represent some visual state. Also I don’t want to force the domain/business objects to fit the screen since that should not be their design goal.

An example scenario

As an simple example imagine a read-only master-details screen for an order and its order lines. The order information such as address etc. is displayed in labels and the order lines are displayed in a ListView. Just for the sake of argument we should also display a running sum for each order line in the ListView and we want to do this by calculating the running sum first and storing it in an extra property that is not available in the domain/business object.  At first I used to handle this kind of scenario by creating the View and ViewModel for the Order and an extra ViewModel class for the order lines. That would give us the following files:

1. OrderView.xaml
2. OrderViewModel.cs
3. OrderLineViewModel.cs

The OrderLineViewModel holds information for each order line including the running sum and the OrderViewModel exposes a property of List<OrderLineViewModel> that the ListView is bound to. The OrderLineViewModel does not have a corresponding View since it is not needed in order to display them in the ListView. After doing this for a while I discovered that this naming convention would make it hard to find the “real” ViewModels that has a corresponding XAML View among the other files. So now we get to the reason for this post, namely what we should name that OrderLineViewModel class!

Reasoning and current solution

The first thing to consider would be to have no suffix at all for this kind of classes. Then the name would be OrderLine, very simple and describing. The problem with that however is that the domain/business object probably also would be named OrderLine but would reside in a different namespace. Now this would work but we would have to qualify the namespaces and it would be hard to distinguish them when reading the code.

Now considering the following:

1. This kind of classes exists only in order to bind to something on the screen.
2. They represent only a part of the screen/view not the whole screen/view like a ViewModel class does.

I first considered the following suffixes:

1. ScreenDataObject
2. ScreenElement
3. PresentationObject

Thinking further I realized the following:

1. This kind of classes often wind up as items in something that inherits from ItemsControl (like ListView or ListBox). So “item” would be more appropriate than “element” to signal it is only a part of the screen.
2. If we wanted to do some advanced styling for each item in the list we would probably create an separate UserControl to use as a DataTemplate. This UserControl would then of course become a View for the Item and the item then would be upgraded/renamed as a “real” ViewModel. So “view” would probably be better than “screen” in the first place.

Adding my thoughts up I came up with the suffix “ViewItem” which I am fairly satisfied with for the time being. Actually “ViewModelItem” would probably be more correct but I decided it was too long. So for the original example we would now have:

1. OrderView.xaml
2. OrderViewModel.cs
3. OrderLineViewItem.cs

Going further with ViewItems

Now I am currently considering if these ViewItem classes should wrap (contain) a domain/business object or if they should have their own members and become a copy of the domain/business object. Obviously they can not derive all their information through a contained business/domain object if they should also contain extra calculated properties. Then they would have to have a reference to the domain object and also some other members for calculated values. I will try to do another post about some reasoning around this soon.