DIAB is now Unity

First of all, we finally came up with a name for the DI container we are building. A drum roll, please… We’ve decided to call it “Unity” as a container that epitomizes a quality of one (system) being, comprising, or consisting of a number (of parts/components). It may not be as descriptive as other blocks but it fits with our vision. We also wanted to distinguish it from other application blocks.

A short description of Unity is a lightweight, extensible dependency injection container.

Unity will provide mechanisms for building instances of objects, which may contain other dependent object instances.

Unity will expose Register methods that support configuring the container with mappings and objects (including singleton instances), and Get methods to return instances of built objects that contain any dependent objects. Note we have purposefully designed the API to support the “fluent interface” pattern. Here’s a preview of the fundamental features of the Unity API, these are very tentative as we are still working on the semantics:

public class UnityContainer : IDisposable {

// getting objects

public T Get<T>(string key){}

public IEnumerable<T> GetAll<T>(){}

// type mapping

public UnityContainer Register<TFrom, TTo>(string key) where TTo : TFrom {}

// singleton support

public UnityContainer SetSingleton<T>(string key) {}

// support for registering existing objects

public UnityContainer RegisterInstance<T>(T existing, string key, bool overload) {}

// running existing objects through the container

public T BuildUp<T>(T existing, string key){}


There are also overloads for non-generics.

So, a typical usage scenario will be:

UnityContainer container = new UnityContainer()

                  .Register<ILogger, TraceLogger>()

                  .Register<ISomething, Something>()
                  .Register<ISomethingElse, SomethingElse>();


As mentioned in our previous postings, Unity will be released in two forms – standalone container and as a part of Enterprise Library 4, with the existing blocks refactored to take advantage of Unity.

Unity will support extensibility via the ContainerExtension mechanism to allow third parties to add support for other on-demand features at runtime, such as event broker.


Comments (19)

  1. bradwils says:

    Your sample usage doesn’t appear to be legal given your interface.

  2. Brad, there are also non-parametrized overloads for those methods – for the sake of simplicity, I’ve only listed one method from each group.

  3. derekgreer says:

    Grigori, while I like the idea of the P&P group providing a container for Object Builder, I would rather an object factory pipeline container be delivered rather than one specifically focused on DI.   Object Builder is currently used for both Dependency Injection (give me service XYZ, generic dependency MyBlah, etc.) as well as for broader Inversion of Control usages (register my events, register my actions, register my commands, register my services, etc.) and can even be used as a general purpose factory (e.g. MyObjectBuilderContainer.Create<MyType>()).

    I understand the desire to provide a simple interface for accomplishing dependency injection, but with this approach it looks like many of us are still going to be left to build our own containers if we want to do stuff like write our own Strategies, Policies, etc (assuming this is still the underlying architecture).

    – Derek

  4. @derekgreer

    Derek, ObjectBuilder is a pipeline. We envision that once Unity is released, you would not need to use ObjectBuilder directly. We’ll provide an extensibility mechanism for Unity and, yes, documentation and examples on how to do it, which hopefully will be a good foundation for what you are trying to do. I’ll do another blog posting on that this week.


  5. FrancoisTanguay says:

    Will Unity provide built-in strategies for interception?

    Also, in the past I needed to register type mappings and singleton instances on a more complex contract than simply a name (key). Complex contracts can include specifications such as: target database, security level required, thread safety, reliability, …

    For that, I was happy with ObjectBuilder which uses an object as the key.

  6. FrancoisTanguay says:

    And I know I’ll have time to write about it when it comes out, but naming wise, I don’t really like TFrom, To… It doesn’t tell much…

    (TInterface or TService) and (TClass or TConcrete) are better imho.

    And I’d make a distinction between Get<T> and Find<T>: Find returns default(T) if not found, Get calls Find and throws if default<T> is returned.

    The former(as posted) increases code that has to be written.

    ILogger logger = container.Get<ILogger>();

    if (logger == null) { throw new ServiceNotFoundException(typeof(ILogger)); }

    logger.Log("Customer Created");

    while the later:

    container.Get<ILogger>().Log("Customer Created");

  7. Deconstructing ObjectBuilder – Introduction

  8. Unity is our new Dependency Injection Container that will soon be available. Read more from Grigori .

  9. Unity is our new Dependency Injection Container that will soon be available. Read more from Grigori

  10. In case you missed it, the "Dependency Injection Application Block" promised for Enterprise Library 4.0

  11. In case you missed it, the &quot;Dependency Injection Application Block&quot; promised for Enterprise

  12. nickp says:

    Instead of the SetSingleton<T> in the public API, it would be nice if you could provide an overload of Register<TFrom, TTo> that would accept a lifestyle of an entity other than singleton such as transient or pooled.

  13. If you’ve been following Grigori Melnik’s blog , you’ll know a bit about Unity , the new Dependency Injection

  14. If you&#39;ve been following Grigori Melnik&#39;s blog , you&#39;ll know a bit about Unity , the new

  15. As many people who read this would know, I’m a big fan of IoC containers, more in particular Castle Windsor

  16. As many people who read this would know, I’m a big fan of IoC containers, more in particular Castle Windsor

  17. nblog says:

    Od kilku miesięcy nic tu nie pisałem (oczywiście poza poprzednim nieplanowanym wpisem ). Jak łatwo się

Skip to main content