• Choose a category
• All
• Classic-Fiction

RegisterType and RegisterInstance are the methods you work with if you opt for configuring the Unity framework programmatically. However, offline configuration is also supported via an ad hoc section in the application’s configuration file. In any case, programmatic and declarative configuration is totally equivalent.

Resolving Dependencies

In Unity, you invoke the method Resolve on the container class to trigger the process that returns an instance of the type at the root of the dependency chain:

container.Resolve(registeredType);

The resolver can be passed any additional information it might need to figure out the correct type to return:

var logger = container.Resolve("Tracing");

If you have multiple registrations for the same type, only the last one remains in the container’s list and will be taken into account. The resolver can walk down the chain of dependencies and resolve everything that needs to be resolved. However, you get an exception if the chain is broken at some point and the resolver can’t locate the proper mapping. When this happens in MEF, instead, the dependency is simply not resolved and is skipped over. On the other hand, multiple candidates to resolve a dependency are managed by Unity (the last wins) but cause a composition exception in MEF.

Declarative Configuration

The Unity framework comes with a custom configuration section that can be merged with the web.config file of a Web application. Here’s the script you need to register types:

Under the section, you list the abstract types mapped to some concrete implementation. The following code shows how to map ILogger to DefaultLogger:

If the type is a generic, you use the following notation:

Taking the declarative approach, you can also select the constructor to be used and set up the lifetime of the instance.

To configure the Unity container with the information in the web.config file, you need the following code:

var container = new UnityContainer();

// Retrieve the section

var section = ConfigurationManager.GetSection("unity") as UnityConfigurationSection;

if (section != null)

{

// Retrieve the specified container by name

var containerElement = section.Containers["MyApp"];

// Load information into the specified instance of the container

if (containerElement != null)

containerElement.Configure(container);

}

As it turns out, Unity allows you to have multiple containers with different settings to load as appropriate. You can skip over all the preceding details by calling an extension method added in Unity 2.0:

var container = new UnityContainer();

container.LoadConfiguration();

It requires that you add a reference to the Microsoft.Practices.Unity.Configuration assembly.

Lifetime Managers

Just like any other IoC framework, Unity allows you to assign a fixed lifetime to any managed instance of mapped types. By default, Unity doesn’t apply any special policy to control the lifetime of the object returned for a registered type. It simply creates a new instance of the type each time you call the Resolve or ResolveAll method. However, the reference to the object is not stored, so a new one is required to serve a successive call.

The default behavior can be modified by using any of the predefined lifetime managers you find in Unity. Table 13-2 lists them.

Table 13-2. Lifetime Managers

Class

Description

ContainerControlledLifetimeManager

Implements a singleton behavior for objects. The object is disposed of when you dispose of the container.

ExternallyControlledLifetimeManager

Implements a singleton behavior, but the container doesn’t hold a reference to the object that will be disposed of when