Example

Presented with a model that I got from colleague, that incidentally helps out as a Hockey Referee when he is not coding, I wanted to create a ViewModel for the use-case “Set up new Hockey game”.

The Game class has a state machine:

I took a piece of paper and draw the UI I wanted to achieve:

Now I know what the requirements are on the ViewModel since I can see from the drawing what data the ViewModel needs to hold.

And then created this ViewModel That I named GameSetup:

Notice that it is just a series of named ocl expressions. Some expressions are nested to other list definitions like Home_PickList that states that if the Game has a picked GameType, then we know what teams that can be picked – namely those teams that are associated to that GameType.

I created some test data so that UI can show something. My first attempt was to manually code a WPF UI and bind the values to the ViewModel:

The UI looks like this:

This has minimal amount of fashion acceptable styling. The good thing is that you can hand it to any WPF savvy designer in the world – the data and the rules are safe in the ViewModel.

It already shows some of the good effects of separating UI from logic.

1. The PickLists for Home and Visitor are filtered based on Type of Game
2. The Picklist for Home team filters away the Visitor team if set (and vice versa)
3. Start game is enabled only after both home and visitor are set
4. The End game button is disabled until the Game is started

These are some examples of business logic that would have easily ended up in the UI if we did not have a good place to define it.

Taking it further still

If the cost of creating and maintaining a ViewModel is high fewer ViewModels will be created. So our mission is to reduce the cost of creating and maintaining them.

WPF is a declarative way to describe the UI. This mean that the same basic lookless components like TextBlock, TextBox, CheckBox, Combobox and Image etc will be used again and again and they will be given a look by an external style or template.

What if we use this fact and provide some basic rendering/placing hints for the ViewModel columns? We could then use those clues to spill out the correct lookless control in the intended relative position so we would not need to mess about with xaml every 5 minutes. This is what the ViewModel-Editor looks like without rendering hints:

And this is the way it looks when I have checked the “Use Placing Hints” checkbox:

Given the extra fields for “Presentation”, “Column”,”Row”,”Span” etc I can work the ViewModel – preview to look like this:

Now I really need to stress this so that I do not get misunderstood: We are not designing the presentation here at all. We are describing what data is available, which values are valid, possible selection lists of data, and, if the UI designer wishes to take notice of it, *hints* as to how to arrange the controls in relation to each other which happens to give the option of generating the userinterface automatically by whatever front end is currently in fashion. This is all natural information we have in mind while designing the ViewModel.

Having a ViewModel with placing hints, you can add a ViewModelWPFUserControl to your form with just one row:

<ecoVM:ViewModelWPFUserControl Grid.Row=”2″ x:Name=”VMU1″
  EcoSpaceType=”{x:Type ecospace:WPFBindingEcoSpace}”
    ViewModelName=”GameSetup” >

And the result is:

And remember that these auto layout controls also adheres to external set styles.

Having the ability to get simple UI automatically derived from the ViewModel placing hints lowers the effort to produce and maintain. Experience has shown that a lot of the administrative parts of your application is left as automated so that more time can be spent on the signature screens that are most important for your users.