ExtensionContext optimization

[ENikS]

ExtensionContext class modifications

Type ExtensionContext provides interface into internals of the Unity Container for custom container extensions . Several areas of the implementation are being improved to allow better flexibility and performance.

Property Container

This property holds a reference to the container that is being extended. Type of this property is changing from IUnityContainer to UnityContainer

/// <summary>
/// The instance of extended container
/// </summary>
/// <value>The instance of <see cref="UnityContainer"/></value>
public abstract UnityContainer Container { get; }

Property Lifetime

This property holds a list of all disposable objects this container required to dispose at the end of its life. Due to deprecation of ILifetimeContainer interface, type of this property changing from ILifetimeContainer to ICollection<IDisposable>.

ILifetimeContainer and ICollection<IDisposable> are member to member compatible and should not require any changes other than type refactoring.

/// <summary>
/// The collection of disposable objects this container is responsible for
/// </summary>
/// <value>The <see cref="ICollection{IDisposable}"/> of <see cref="IDisposable"/> objects</value>
public abstract ICollection<IDisposable> Lifetime { get; }

Build strategies Strategies

Legacy design provides a build chain with strategies required to process registrations and allows setting them up for each child container. This feature is quite expensive in terms of performance and provides just a marginal value. For more info see #227

Most of customization in child containers are done on policy and registration level. Things like steps in type initialization or constructor selection are kept the same throughout the whole hierarchy. To optimize how these build chains are used new version implements the following:

Individual build chains for Type, Instance, and Factory registrations

Due to different build requirements for each of these registrations, build chains are split into four, with each containing only strategies relevant to specific chain type:

/// <summary>
/// Pipeline chain required to process type registrations
/// </summary>
public abstract IStagedStrategyChain TypePipelineChain { get; }

/// <summary>
/// Pipeline chain required to process instance registrations
/// </summary>
public abstract IStagedStrategyChain InstancePipelineChain { get; }

/// <summary>
/// Pipeline chain required to process factory registrations
/// </summary>
public abstract IStagedStrategyChain FactoryPipelineChain { get; }

Build chains are shared between hierarchies

New version will no longer support build strategies in child containers. There will be only one instance of build chains. Every child container will be sharing the same pipeline as the root container.

Optimize events

Events are called when either type or instance are registered or child container is created. There are several problems with this implementation:

• Event invocation requires instantiation of wrapper classes RegisterEventArgs, RegisterInstanceEventArgs, ChildContainerCreatedEventArgs and adds a lot of overhead.
• No event for factory registration
• The implementation uses generic EventHandler<T> designed for general purpose cases and not very performant.

For more info see #188