In my last post I covered basic topics about Caliburn and Caliburn.Micro. Lets look into the core infrastructure.
Bootstrapper
In short terms the Bootstrapper is responsible to configure the framework and provides extension points to hook in various Inversion of Control containers. The generic variant of the Bootstrapper allows defining which view acts as the main view (view-first) or which view model acts as the main model (view-model-first) of the application.
The Bootstrapper can either be defined as application resource in the applications resource dictionary or in code.
PropertyChangedBase
In short terms the PropertyChangedBase implements INotifyPropertyChanged and offers simple helper methods to raise property changed events without using magic strings. Expression trees are used as magic tool behind the scenes.
ViewAware
In short terms the ViewAware is a base class which inherits from PropertyChangedBase. Its single responsibility is to hold and cache the view retrieved by the conventions which belongs to the corresponding view model.
Screen
In short terms the Screen is a base class which inherits from ViewAware. Its responsibility is to manage the lifecycle of a screen regarding initialization, activation, deactivation and closing.
Conductor
In short terms the Conductor is a base class which inherits from Screen. Its responsibility is to conduct other objects by managing an active item and maintain a strict lifecycle of this conducted item. The conductor exists in multiple variants such as the one item conductor simple called Conductor, the multiple item conductors such as Conductor.Collection.OneActive and Conductor.Collection.AllActive.
Conventions
There are multiple conventions acting behind the scenes in Caliburn.Micro. The most important conventions to understand are the view resolution (ViewModel-First) and the view model resolution (View-first) conventions. The view resolution convention resolves views according to the following convention: CustomerViewModel -> CustomerView (built-in). The view model resolution convention resolves view models according to the following convention: CustomerView -> CustomerViewModel (built-in).
Although Caliburn.Micro offers view first conventions it is advised to use the view model first approach because it leads generally to a better architectural composition of the application. All conventions can be extended or overwritten. For example the view model and view conventions can be customized by using the NameTransformer.
Conventions are applied almost everywhere in Caliburn.Micro such as action and guard conventions and many more but this is not topic of this article.
Coroutines
In short terms coroutines are operations which can be bound to a view model and executed asynchronously. Coroutines can be chained together into a sequential workflow of operations. Coroutines are automatically built up by the framework and can therefore profit from dependency injection mechanism if available. Coroutines can be cancelled and can intercept exceptions. Caliburn.Micro automatically aborts the execution of coroutines in case of a cancellation or an exception.
Actions
Actions can execute any operation on view models which can also be coroutines. Actions are dispatched/triggered with System.Windows.Interactivity triggers. Actions are message based and can bubble up the visual tree until they got handled. When a bubbling action is not handled the framework calls a rescue handler which can decide whether the action is generically handled or thrown away. Actions can be conditionally executed by applying guard actions which are first called before the actual action is triggered. Action can also take parameters which are passed to the underlying action method on the view model. All in all actions are the ultimate powerful weapon when it comes to advanced interaction scenarios such as executing custom loading operations asynchronously.
Migration Caliburn to Caliburn.Micro
We are currently migrating a large code base from Caliburn to Caliburn.Micro. So far the migration was pretty painless. Here are some of the issues you might encounter when migrating:
- Namespace Caliburn.Micro instead of Caliburn
- System.Windows.Interactivity instead of Caliburn triggers
- Some renamings of core infrastructure for example
- Results ActionExecutionContext instead of ResultExecutionContext
- Bootstrapper Integration
The time consuming aspect of the migration is that we need to retest the whole client.
Summary
You shouldn’t use Caliburn. Caliburn is officially declared as a legacy framework and only maintained to support existing apps. All future development is focused on Caliburn.Micro. If you start a new project then start with Caliburn.Micro. Stick to the functionality provided by Caliburn.Micro. If anytime the necessity occurs for more advanced features offered by the full framework, then it is often easy possible to migrate some of the concepts to Caliburn.Micro.
