Before Catel 2.0, the IoC container used internally was Unity. However, this forced all users to use and configure Unity as the IoC container in their apps and required the shipping of the libraries as well. Since Catel 2.0, a different technique is used which allows the end-developer to use the IoC container technique of their choice.

Also see:

ServiceLocator

Catel uses it's own ServiceLocator implementing the IServiceLocator to gather all services required by Catel. For example, default services are the IPleaseWaitService and the IUIVisualizerService. By default, when the first view model is instantiated, Catel registers all default out of the box services to the ServiceLocator. However, it only does this when the specific services are not already registered. This allows an end-developer to register his/her own implementations of the services before any view model is instantiated (for example, at application startup).

The ServiceLocator can be instantiated, but Catel instantiates one instance that can be used and shared amongst all objects inside the same AppDomain. The ServiceLocator can be retrieved by using ServiceLocator.Instance. The ViewModelBase implements GetService which internally calls ServiceLocator.ResolveType. This way, the end-developer does not have to think about instantiating or retrieving the right ServiceLocator, but can simply use GetService to retrieve the implementation of a specific registered interface.

Registering a type

Registering a type in the ServiceLocator is very simple and works like any other IoC container:

ServiceLocator.Default.RegisterType<IPleaseWaitService, PleaseWaitService>();

Registering an instance of a type

Catel uses Activator.CreateInstance to create the interface implementations when the object is first resolved. However, sometimes a service constructor requires parameters or takes a long time to construct. In such cases, it is recommended to create the type manually and register the instance of the type:

var pleaseWaitService = new PleaseWaitService();
ServiceLocator.Default.RegisterInstance<IPleaseWaitService>(pleaseWaitService);

Registering a type via MissingType event

The ServiceLocator gives the end-developer a last-resort chance to register a type when it is not registered in the ServiceLocator or any of the external containers. This event is very useful for logging (then the developer in the log knows exactly what type is missing from the IoC container) or it can be used to determine at runtime in a very late stage what implementation of the service must be used. To register a type via the event, subscribe to the event and then use the following code:

private void OnMissingType(object sender, MissingTypeEventArgs e)
{
    if (e.InterfaceType == typeof(IPleaseWaitService))
    {
        // Register an instance
        e.ImplementingInstance = new PleaseWaitService();

        // Or a type
        e.ImplementingType = typeof(PleaseWaitService);
    }
}

If both the ImplementingInstance and ImplementingType are filled, the ImplementingIntance will be used.

Resolving a type

To retrieve the implementation of a service, use the following code:

var pleaseWaitService = ServiceLocator.Default.ResolveType<IPleaseWaitService>();

Registering external containers

As explained earlier, the ServiceLocator supports external containers to make sure that the end-developer can use the IoC container of his/her choice and is not forced by Catel to use any specific IoC implementation. Registering a container is very simple and can be done at any time (but, must of course be done before service registered in the external container can be used by the ServiceLocator itself):

ServiceLocator.Default.RegisterExternalContainer(myUnityContainer);

Registering an external container makes it possible to resolve types from the ServiceLocator that are originally registered in the external container. For example, a database repository is registered in Unity, but must be used inside a view model. This is what happens:

End-developer registers ICustomerRepository in a Unity container
End-developer registers the external container in the ServiceLocator of Catel
In a view model, the developer uses GetService<ICustomerRepository>() to retrieve the repository
Internally, the ServiceLocator checks which external container has the type and uses that specific container to return the type

Synchronization between containers

Until now, it all seems very nice. However, there are some aspects that are very hard and which must be taken into account. For example, think of the following issues:

Instance caching
Which container is the actual owner of a type?

Synchronization from external containers to ServiceLocator

Internally, the ServiceLocator keeps a reference of all registered types in the internal container, all instantiated types and the original container per type. For example, think of the following situation:

A type is registered in Unity (but the ServiceLocator does not know whether it's a type or instance since Unity makes no difference between them)
A developer resolves the type in the container

The ServiceLocator checks whether there is already an instance created or requested earlier by the developer. If it already has an instance in the cache, it simply returns the instance from the cache. If not, it checks which container (it might be itself, but also one of the external containers) is the owner of the type. A container is considered the owner if the type was first found on that specific container. The ServiceLocator lets the external container (in this case Unity) instantiate the type. Then the ServiceLocator stores the instance in the instance cache so it can be easily resolved in the next call.

Synchronization from ServiceLocator to external containers

Great, now think of this situation:

A type is registered in the ServiceLocator
The type must be injected into a constructor using Unity

This is a bit harder because the type is not registered in Unity, but it is used by Unity. Luckily, the ServiceLocator is able to automatically register types in all external containers as soon as a type is registered or resolved. This way, when a type is registered in the ServiceLocator, it automatically calls ExternalContainer.RegisterType (or (ExternalContainer.RegisterInstance in case of an instance) for all external containers. This way, it is possible to register a type in the ServiceLocator, but still be able to use the powerful dependency injection of Unity.

Automatic or manual synchronization

By default, the ServiceLocator automatically keeps all the IoC containers in sync so the end-developer should not have any knowledge of the inner workings of the ServiceLocator. Sometimes, a developer wants to have more control and needs to disable this automatic behavior. This is possible using the following property:

ServiceLocator.Instance.AutomaticallyKeepContainersSynchronized = false;

Then it is still possible to manually synchronize the containers using the following methods:

ExportInstancesToExternalContainers => exports instances only
ExportToExternalContainers => exports instances and registered types

External containers that only support instances

There are external containers, such as MEF, that only support the registration of instances, not types. If such an external container is registered, all the types registered in the ServiceLocator are instantiated and registered as an instance in the external container. If this behavior is not acceptable, disable the automatic synchronization and handle the synchronization manually via the AutomaticallyKeepContainersSynchronized property.

External containers supported

Currently, the following external IoC containers are supported:

Castle Windsor
MEF
Ninject
Unity

If there is need for other containers, just let us know!

Advanced information

The ServiceLocator is a pretty advanced implementation of IoC without the requirements of any reference to, for example, Unity. There are a few inner workings that are very important that are explained in this section. Internally, this is the workflow that the ServiceLocator use to resolve types:

Check if an instance is already created so it can be returned
Check if the type is registered in the ServiceLocator itself
Loop all external containers and check whether the type is registered there
If the ServiceLocator nor the external containers have the type registered, the ServiceLocator raises the MissingType event which gives the developer a last opportunity to either log the missing type or register it via the event

Catel - 3.5

IoC (ServiceLocator and TypeFactory)