Part I: The basement
Part II: From basement to second floor
First of all I want to tell what Caliburn.Micro (herein after referred to as CM) actually is.
”A small, yet powerful implementation of Caliburn designed for WPF, Silverlight and WP7. The framework implements a variety of UI patterns for solving real-world problems. Patterns that are enabled include MVC, MVP, Presentation Model (MVVM), and Application Controller.” Caliburn.Micro on CodePlex
When I started using CM I was surprised how easy DataBinding in WPF can be. CM handles the binding with implemented naming conventions, so the view “ModuleAView” is bound to the viewmodel “ModuleAViewModel” just by removing the "”model” part from the viewmodels name. Controls are bound by name too. A Button named “SayHello” (x:Name=”SayHello” in XAML) is bound to the method “SayHello()” in the related viewmodel. Seems to be easy, doesn’t it?
Now, let’s come to the core of this post: the module-based application using CM. To give an idea what is meant with a module-based application, take a look at the following draft: 
There’s the main application window (ShellView by default, can be renamed) containing a collection of separate modules. Each module contains a collection of different module screens. This examples constraint is, that only one module is active/displayed and only one screen of the active module is displayed. Let’s take a look to some source code…
(NOTE: Because this is a very simple example, I did not structure the project like I normally do.)
Shell (ShellView + ShellViewModel)
ShellView.xaml
<Window x:Class="CaliburnMicroWPF.ShellView" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> <Grid Background="White"> <ContentControl x:Name="ActiveItem"/> </Grid> </Window>
ShellViewModel.cs
using System.ComponentModel.Composition; namespace CaliburnMicroWPF { [Export(typeof(IShell))] public class ShellViewModel : IShell { } }
That’s the basement of the application. To get the modularity, it needs to create views and viewmodels for every module and every screen as well. The navigation logic has to be implemented either in the shell, the modules or in the screens themself. My favourite approach is an event-based navigation to get a well-separated application. Therefor CM provides its own EventAggregator which is accessible with
IoC.Get<IEventAggregator>()
For more information about the EventAggregator look here.
To the end of this part, there’s our basement consisting of the ShellView and the related ShellViewModel as the top-level. You can download the example project here. In the next part, the modules will be added to the project to provide the second-level of the module-based application.
