Released Catel 3.2

The Catel team is very proud the announce the new 3.2 release. As always, the new version is available viaNuGet and via Codeplex (http://catel.codeplex.com).

In this blog post, I will try to explain the most important new changes in Catel.

Dependency injection support in the ServiceLocator

The ServiceLocator in Catel now fully supports dependency injection. This means that when a type is being resolved from the ServiceLocator.

Dependency injection via the ServiceLocator in Catel is enabled by default. This means that when a type is resolved from the container, it will automatically use dependency injection to construct the type if it is not registered as instance.

It will first search for all available constructors on the type that will be instantiated. Then, for each constructor, starting with the one with the most parameters, it will try to retrieve all values. If one fails, it will go to the next. If all fail, it will try to use the default constructor without parameters. If that fails as well, then the type cannot be constructed and an exception will be thrown.

To get a better understanding of what happens, see the class below:

When the MyClass will be retrieved from the ServiceLocator, this will happen:

  1. Find constructor with most parameters (the one with both firstDependency and secondDependency). If both IFirstDependency and ISecondDependency can be resolved from the ServiceLocator, the type will be constructed with the constructor. Otherwise it will proceed with step 2.
  2. Find next constructor with most parameters (the one with only firstDependency). If IFirstDependencycan be resolved from the ServiceLocator, the type will be constructed with the constructor. Otherwise it will proceed with step 3.
  3. At this point, no constructor could be used. In this case, the ServiceLocator will try to use the default constructor (the one without parameters) as last resort to instantiate the type.

Introducing the ViewModelFactory

In previous versions of Catel, it was only possible to inject a datacontext into a view model. In Catel 3.2, the new ViewModelFactory is introduced. This class is responsible for instantiating the view model.

By default, the implementation does exactly the same as before, but this gives great freedom when the view models cannot be instantiated by Catel itself (for example, when dependency injection is used, or when the registered view models of a control are interfaces).

Below is an example of a custom implementation of a view model factory:

All reflection is cached

In preparation for WinRT support, we moved all reflection to a single class with extension methods. This was a great opportunity to add caching to all reflection.

This means that all reflection is cached on the first call. This provides major performance improvements when using reflection.

More flexible behavior base classes

Catel already provided memory leak free base classes for behaviors and triggers. In the new version, a few new base classes are introduced to allow faster behavior developmentP:

  • CommandBehaviorBase – supports a command, command parameter and key modifiers out of the box
  • UpdateBindingBehaviorBase – supports binding updates on dynamic dependency properties

Core services now only use interfaces for MVVM integration

The core services (such as the MVVM behaviors) in Catel now use interfaces such as INotifyableViewModeland IRelationViewmodel. This makes it possible to use different base classes for view models and still use the full potential of Catel.

Updated to latest external libraries

We also took the time to update all external libraries to the latest version. The following libraries were updated:

  • Ninject (3.0)
  • Castle.Windsor (3.0)
  • FluentValidation (3.3.1)