This topic describes the concept of dependency injection and IoC Container, and explains how to use the built-in IoC Container in ClientUI to build extensible applications with highly modular and loosely coupled architecture.

Understanding Inversion-of-Control (IoC)

Inversion-of-Control (IoC) is a design pattern that inverts the flow of the application logic, which is achieved through the use of Dependency Injection for its binding process. The goal of this design pattern is to achieve maximum loose coupling where dependencies can be minimized or completely eliminated. With this approach, the application code can be easily extended as the concrete implementation can be dynamically specified or changed at runtime.

IoC is commonly paired with abstraction pattern such as dependency injection which enables the dependency to be resolved at latter time and injected to the control. The most common dependency injection approach is constructor injection.

The following code shows an example of a simple class that complies to the dependency injection pattern.

public class MyStore
{
    public MyStore(IPaymentProcessor paymentProcessor)
    {
        if (paymentProcessor == null)
            throw new ArgumentNullException("paymentProcessor");

        this.PaymentProcessor = paymentProcessor;
    }

    public bool ProcessTransaction(ITransaction transaction)
    {
        return this.PaymentProcessor.ProcessPayment(transaction);
    }

    protected IPaymentProcessor PaymentProcessor { get; set; }
}

The example above uses constructor injection, which means that the code itself does not depend on specific implementations. Instead, the type that contains the concrete implementation is injected externally via the parameter in the constructor. The following code demonstrates the usage of the above class.

public class MainPageViewModel : ViewModelBase
{
    private void ExecuteProcess()
    {
        MyStore myStore = new MyStore(new PayPalPaymentProcessor());
        myStore.ProcessTransaction(transaction);
    }
}

As seen in the code above, the class can be easily instantiated from any modules in the application such as ViewModel in MVVM-based applications. With the common class construction such as illustrated in the above example, however, it introduces a dependency on MyStore class which makes it difficult to extend in the future.

Introducing IoC Container

One of the well-known techniques to eliminate type dependencies is by inverting the flow of the logic to the controller host or also known as IoC container which manages the type registration, resolution and the life-cycle of the dependencies.

In constrast to the example in previous section, the following example shows the code that has been rewritten to use IoC container. 

public class MainPageViewModel : ViewModelBase
{
    private void ExecuteProcess()
    {
        IStore store = Container.Resolve<IStore>();
        store.ProcessTransaction(transaction);
    }
}

Notice that the class no longer depends on any concrete types. Instead, the IoC container will resolve an instance of object that implements IStore at runtime.

At the heart of IoC container are the Register and Resolve methods, which perform the following:

• Register: Register a dependency by associating the abstract type or interface to the concrete type
• Resolve: Resolve an instance of the dependency by looking up the exact registration in the container

Most of the dependency registrations are usually done in a centralized place, commonly invoked when the program initializes. This centralized place is called Composition Root, which allows you to manage the composition of all components and services in a single place.

The following code shows how to use the Register method in the application initializer to register an interface type to a concrete type.

public class AppInitializer : IApplicationInitializer
{
    public void Initialize(ApplicationPackage package)
    {
        IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

        // Register the IStore interface to compose a new PayPalPaymentProcessor through a direct construction
        container.Register&tl;IStore>(o => new MyStore(new PayPalPaymentProcessor()));
    }
}

The code above is self explanatory – it registers the IStore interface type to a function that returns a new MyStore class complete with the required dependencies which is the PayPalPaymentProvider in this example.

IoC Container API and Features

Built with lightweight object factory, ClientUI provides comprehensive library to work with IoC container which supports a host of advanced container features such as open-generic support, lazy resolution, named containers and built-in lifetime managers.

Basic Type Registration

ClientUI IoC container includes a number of overloads to perform type registration and resolution. The most basic APIs for type registration and resolution are as follow:

• Register<TType, TImpl>()
• Register(Type tType, Type tImpl)
• Register<TType>(Func<IDependencyResolver, TType> func)
• Resolve<TType>()
• Resolve(Type type)

IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

// simple registration
container.Register<IStore, MyStore>();

// registration with parameterized constructor
container.Register<IStore>(o => new MyStore(new PayPalPaymentProcessor()));

// registration with nested resolve where the IPaymentProcessor is first resolved by the container to be passed into MyStore
container.Register<IPaymentProcessor, PayPalPaymentProcessor>();
container.Register<IStore>(o => new MyStore(o.Resolve<IPaymentProcessor>()));

// resolve a new instance of IStore
IStore store = container.Resolve<IStore>();

Instance Resolution

In addition to the common resolution that returns a new instance of the specified type, ClientUI IoC container also supports instance-based registration and resolution. This allows you to register an existing object instance into the container. During resolve, the container will return the registered object instead of creating a new instance.

You use the following methods to register an existing object instance:

• RegisterInstance<TType>(TType instance)
• RegisterInstance(Type type, object instance)

IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

GooglePaymentProcessor googleProcessor = new GooglePaymentProcessor();
googleProcessor.Url = "https://checkout.google.com";
// initialize default properties of the processor

container.RegisterInstance<IPaymentProcessor>(googleProcessor);

Named Containers

By default, you can define only one registration with the same type at one time. However, there are numerous scenarios that might require you to define multiple registrations with the same interface type but associated to different implementation types. The IoC container library in ClientUI supports named containers that allow you to achieve this scenario by using different naming scope.

You use the following method overloads to register and resolve type using named containers:

• Register<TType, TImpl>(string name)
• Register<TType>(string name, Func<IDependencyResolver, TType> func)
• Register(string name, Type type, Func<IDependencyResolver, object> func)
• Register(string name, Type tType, Type tImpl)
• RegisterInstance<TType>(string name, TType instance)
• RegisterInstance(string name, Type type, object instance)
• Resolve<TType>(string name)
• Resolve(string name, Type type)

IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

// registration with named containers
container.Register<IStore>("Main", o => new MyStore(new PayPalPaymentProcessor()));
container.Register<IStore>("Alternate", o => new MyStore(new GooglePaymentProcessor()));

// resolve type from named containers
IStore store = Container.Resolve<IStore>("Alternate");
store.ProcessTransaction(null);

Lazy Resolution

In certain scenarios, you may want to defer the creation of an object, particularly when the object is complex and may allocate relatively large system resources. The IoC container supports lazy resolution which is ideal to achieve this kind of scenarios.

You use the following methods to perform lazy resolution:

• LazyResolve<TType>()
• LazyResolve<TType>(string name)
• LazyResolve(Type type)
• LazyResolve(string name, Type type) 

When the lazy resolution is used, the container returns a function that wraps the type instead of the real instance of the type. Whenever required, you can then execute the returned delegate function to get an object instance of the type.

IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

Func<IStore> fnStore = Container.Current.LazyResolve<IStore>();

// An instance of the IStore type is not created yet during Resolve.
// To access the real instance, execute the delegate function.
IStore store = fnStore();
store.ProcessTransaction(null);

Lifetime Manager

In addition to type registration and resolution, IoC container also serves as the controller that manages the lifetime of each dependency it generates. For instances, you may want to have the container to always create a new instance of the dependency, or alternatively, cache the instance for sharing use across multiple modules.

The built-in lifetime managers included in the ClientUI Framework are: 

• AlwaysNewLifetime
  This is the default lifetime manager used in all registration methods. This lifetime manager creates a new instance of the type when the Resolve method is called.
   
• ContainerLifetime
  This lifetime manager creates a new instance only once, then returns the same instance in the subsequent Resolve method calls. 

To specify a lifetime manager in a specific registration, use the WithLifetimeManager method filled with the lifetime manager as the parameter.

IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

container.Register<IStore>("GlobalCache", o => new MyStore(o.Resolve<IPaymentProcessor>()))
                             .WithLifetimeManager(new ContainerLifetime());

// Using Container lifetime, also known as shared registration,
// the container will instantiate a new object once for the first time 
// and return the same instance in the subsequent resolve calls.

IStore store = Container.Resolve<IStore>("GlobalCache");
IStore store2 = Container.Resolve<IStore>("GlobalCache");

if (store == store2)
    MessageBox.Show("Store and Store2 instance are equal");

 Integration with ClientUI Application Framework

The IoC container implemented in the ClientUI Framework supports both standalone usage and integration with UXShell. For most common scenarios, it’s recommended that you use the default container instance which is accessible from the shell’s Container property. This technique enables you to resolve the registered dependencies anywhere in your code, including the dynamic XAP applications that are loaded on demand at runtime. For more information about ClientUI Application Framework, see Application Framework Overview.

In addition, the application framework now introduces a built-in bootstrapper to facilitate the dependencies composition and registration. Simply add a class that implements IApplicationInitializer interface in your projects, the Initialize method of the class will be automatically invoked when the application starts. In dynamic XAP scenarios, the Initialize method will be automatically invoked when the XAP package is downloaded and loaded to the application domain.

The following code example shows a class that implements IApplicationInitializer interface which contains the composition for the dependencies available in the module.

namespace ClientUI_Ioc
{
    // The class that implements IApplicationInitializer will be automatically instantiated
    // by ClientUI Application Framework when the application starts. 
    // In dynamic XAP scenario, it will be called when the module is 
    // loaded to the app domain through ClientUI application framework.
    public class AppInitializer : IApplicationInitializer
    {
        #region IApplicationInitializer Members

        public void Initialize(ApplicationPackage package)
        {
            // The technique of writing registration code in a centralized place is also known as "Composition Root"
            // which allows you to overview all components registration and easily maintain it for future extensibility.

            IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

            // Register the IStore interface to return a new PayPalPaymentProcessor through a direct construction
            container.Register<IStore>(o => new MyStore(new PayPalPaymentProcessor()));

            // Instance-registration sample

            GooglePaymentProcessor googleProcessor = new GooglePaymentProcessor();
            // initialize default properties of the processor
            container.RegisterInstance<IPaymentProcessor>(googleProcessor);

            // Use Container lifetime manager to return shared instance of myStore
            container.Register<IStore>("Lifetime", o => new MyStore(o.Resolve())).WithLifetimeManager(new ContainerLifetime());

            // Named container sample
            container.Register<IStore>("Alternate", o => new MyStore(new GooglePaymentProcessor()));
        }

        #endregion
    }
}