I’ve been looking at the Caliburn Micro Framework for a new WPF desktop application I need to write. This app is to replace another I wrote in 2006 using the Composite Application Block. So I was reviewing some of the more recent frameworks such as Prism and discovered both Caliburn and Caliburn Micro on Codeplex.

Caliburn Micro is a very lightweight framework for helping you build MVVM applications by handling all the plumbing between the View and the ViewModel. It does this by requiring you to adopt some naming conventions – the View must be named the same as the ViewModel with the Model removed, then it will bind together any properties it finds on the View and ViewModel that have the same name.

This technique dramatically reduces the amount of code you need to write, and indeed the View’s code behind needs no extra code other than the default.

As you look at the many Caliburn Micro demo programs on Codeplex and the web in general I found they were all single solution. Before committing to using this framework I wanted to be sure I understood the basic concepts in particular how I would work with multiple modules with no hard references, in a standard Prism/MEF fashion. So the obvious question is, without Prism, how can a Module find a the place in the Shell where it should be displayed. If you know Prism it has the concept of Regions and a RegionManager that allows the Shell to specify a name for a Region and a Module to find that named Region all without references between the Module and the Shell. Clearly, MEF will instantiate the Module for you, but it isn’t going to do the binding for you.

I concluded (wrongly as it turns out) that I would have to manually bind the Module’s View and ViewModel into the correct place in the Shell or write a simple Region/RegionManager concept. If fact I did write a simple “control finder” that the Module can use once it imports a reference to the Shell.

Anyway I posted a question on Codeplex  requesting some help on this and to cut a story short, the originator of Caliburn Micro, Rob Eisenberg, kindly stepped in with an example.

The way the example works to bind a Module’s View into a place in the Shell is so simple that it’s worth documenting here.

I assume you know MEF, and so it will be no surprise to you that you can have a property in the ShellViewModel that imports a Module’s ViewModel. In the code fragment below, the interface IView1Model is in a Contracts class and the actual implementation is in a class library called Module1. Module1 has the conventional Post Build copy task to the program’s bin/Debug directory.

//ShellViewModel fragment
[Export(typeof(IShell))]
public class ShellViewModel : Screen, IShell
{
    IView1Model one;

    [Import(typeof(IView1Model), AllowDefault = true)]
    public IView1Model One 
    {
        get { return one; }
        set {
            one = value;
            NotifyOfPropertyChange(() => One);
        }
    }

The import is standard MEF, and AllowDefault = true is needed to ensure the Shell is instantiated by MEF even if the Module cannot be found.

So far so good. Now look at the Xaml fragment of the Shell’s view.

<StackPanel>
    <TextBlock x:Name=”Title” TextAlignment=”Center” FontWeight=”Bold” />
    <GroupBox Height=”100″>
        <GroupBox.Header>Module1, View1Model here</GroupBox.Header>
        <ContentControl x:Name=”One” />
    </GroupBox>

Caliburn Micro will then bind the name of the ContentControl to the ShellViewModel’s One property, which happens to be the Module’s ViewModel and magically the View appears in the Shell.

Now depending on how much of a Prism purist you are, if you are willing for the Shell to use an interface name from the Module, Caliburn Micro will do it for you. But,  if you really want the Shell to be kept clear of any  connection with your Module, you’ll have to use the Region concept from Prism.

Update:
In the discussion on Codeplex, Richard posts a solution using two buttons to load different Modules into a place in the Shell. His solution uses cal:View.Model in the Xaml, which based on Robert’s example is not really necessary as it can be done with only properties. I’ve added that to the solution attached.

Notes:
MEF has now been incorporated into .Net 4 and Silverlight 4 , so the Codeplex site is out of date in only referring to the early development.

MultipleModulesDemo.zip (692.89 kb)