Core Series Part 2b – Automatic template selection (this time real automatic selection!)

In the previous post I demonstrated the concept of automatic template selection in a very very simple way. The post was designed to demonstrate the concepts that will be applied in this post – you really shouldn’t use the methods described in the previous post in real projects!

This series is starting out covering off some very basic concepts that are important to understand before progressively up the complexity until we jump in the a full solution – so be patient if you find this stuff a little simple for your tastes!

In this post I will demonstrate a very simple way to apply convention to automatically select a View for the current ViewModel.

Convention is great – as long as you follow the convention (creating files with the correct names, and putting them in the correct spot) this it will “just work”. Yeah I know, never say it will “just work” – phrases like that curse software projects 🙂

Once again to reiterate, the ViewModels do not have any idea what View will be displayed… and you should always try to achieve this in your projects. As soon as the ViewModel knows about the View you are risking breaking all manner of software dev rules, but more importantly your code will lack elegance and be far harder to create and maintain. With this in mind, we “publish” the current ViewModel through a property in the “frame” – the frame being the VM (ViewModel) that looks after creating and displaying child VM’s, and eventually in later posts navigation and tombstoning etc. The VM is then picked up by a ContentControl which will then figure out which View to show. The frame is on the VM side of the fence, the ContentControl is on the View side of the fence. The link between the fence is DataBinding.

Example – automatic view selection using convention

First, you can download the example here.

You can view a video run through of the example here.

The code examines how to pass in a VM to the ContentControl and automatically resolve the view to show.

There are two concepts that are important to take away from this example: first is convention. Creating Views called xxxView and VMs called xxxViewModel. The ContentTemplateSelector is then called upon to look at the type names, figure out the View to show (by replacing ViewModel with View from the original VM type name), then dynamically building some XAML which contains a DataTemplate.

The second concept is of course the dynamic generation of a DataTemplate. It’s important to note that child controls in DataTemplates are not ingratiated when the DataTemplate is created – it’s not until the DataTemplate is applied against some content (in this case the VM) in the ContentControl. This is nice, it means we can cache the DataTemplate to negate the need to re-generate them when the same VM type is used next time.

The XamlReader is used to process the dynamic XAML and returns a DataTemplate, which the ContentControl sets to it’s ContentTemplate property at runtime.

So what’s the benefit?

Convention is great for writing code and building projects *fast*. To add a new View using this system takes minutes (if not seconds). Navigating to the new view is very simple also.

In the next post we will example some further benefits of letting the “View” side of the fence handle control resolution – mainly automatic, designer friendly, centrally managed content transitions!

Core Series Part 2 – Automatic template selection – marrying a view to a view model

This is the second part of my series on a different approach to MVVM. I highly recommend you read part one to get some background.

This series introduces concepts around MVVM – mainly around view and viewmodel selection, navigation and transitions. The concepts here can be applied to WP7, Silverlight or WPF (including Surface). Further on in the series I will demonstrate how simple more advanced topics like circular navigation and tombstoning can be made (very) simple. All of the techniques I talk about in this series are implemented in XamlingCore – an simple reference MVVM framework. You may choose to use XamlingCore or take the concepts from this series and use them as you please. I recommend you at least have the XamlingCore code available on your system as I will reference files here and there from the framework.

Keeping things simple

A big part of MVVM is figuring out how to match up the view to the view models that you create. Typically for each view, there is a view model (simple right??). Making this process as intuitive and straightforward as possible is very important.

XamlingCore works a little bit different than you may be used to. In XamlingCore you first create a viewmodel and then navigate to your new viewmodel… this is a little different than other systems – where you first create a view and the viewmodel is then “discovered”. This is called ViewModel first navigation.

I really like ViewModel first navigation – for a few simple reasons. Firstly – your code is completely agnostic to what the view is doing… in fact you could create all your ViewModels and navigate around your application without any views being generated at all! This makes it really easy to test. Secondly the very fact that the ViewModel side is completely view agnostic means that you are achieving a very high level of separation of concerns. It also allows for a really simple navigation system (you just keep your ViewModels in a stack, then pop them as the user navigates back).

The main reason I like this method however is that you create ViewModels just like you would any other object, calling constructors, properties etc to pass around data – and I’ll show some great things you can do with this later.

It may sound a little complex, but in practice it’s actually *really* simple.

ViewModel/View Marriage

The main concept we want to achieve is that ViewModels only worry about themselves, and the view side of the fence handles everything to do with choosing how to display the ViewModels (which templates, user controls etc to choose). This keeps the ViewModels very simple. The view stuff makes sense on the “view side”.

At the top level of our application there will be a NavigationFrame – much like the in built navigation system in Silverlight/WP7. The navigation frame has both View and ViewModel side components. It is responsible for taking the current ViewModel and displaying the appropriate view.

The basic workflow is: Construct new ViewModel -> Navigate to it -> Navigation presents the ViewModel to the frame -> frame resolves and creates view (via a DataTemplate) -> hands off ViewModel and new DataTemplate to a content control for display.

A really simple example

I have prepared a really simple example that demonstrates this basic workflow to give you a more hands on idea about how this would work.

Download the sample here.

View the quick screen cast here.

Obviously this sample wouldn’t work very well in the real world, but it demonstrates the concept of choosing a template based on the ViewModel type that is being shown in the ContentControl.

In the next part we will move on to a more automated, convention based approach!

Happy MVVMing!