IoC Benchmark

So which is the fastest at different IoC Lifestyles.

In this benchmark we will be running, head to had, with Castle Windsor, Ninject, Spring.NET, Unity, Microsoft DI, AutoFac, and Structure Map.

Here is a working project, this uses NuGet to included the packages, so as time goes on you may find the packages go out of date, so you’ll need to refactor the code to work with the next packages.

I’m using a Parallel test as this represents a closer real life example of how the containers will be used.

ioc-benchmark

 

Factory Support Facility

Factory Support Facility allows using factories to create components. This is beneficial when you want to make available as services components that do not have accessible constructor, or that you don’t instantiate, like HttpContext.

Prefer UsingFactoryMethod over this facility: while the facility provides programmatic API it is deprecated and its usage is discouraged and won’t be discussed here. Recommended approach is to use UsingFactoryMethod method of fluent registration API to create components. This limits the usefulness of the facility to XML-driven and legacy scenarios.

UsingFactoryMethod does not require this facility anymore: In older versions of Windsor (up to and including version 2.1) UsingFactoryMethod method in the fluent API discussed above required this facility to be active in the container. That was later changed and there’s no such dependency anymore.

Using factories from configuration

In addition to code, the facility uses XML configuration. You can register the facility in the standard facilities section of Windsor’s config:

Just install the facility and add the proper configuration.

<configuration>
 <facilities>
   <facility
     id="factory.support"
     type="Castle.Facilities.FactorySupport.FactorySupportFacility, 
           Castle.Facilities.FactorySupport" />
  </facilities>
</configuration>

Configuration Schema

Broadly speaking facility exposes the following scheme, with two kinds of supported factories: accessors and methods

<components>
 <component id="mycomp1" instance-accessor="Static accessor name" />
 <component id="factory1" />
 <component id="mycomp2" factoryId="factory1" factoryCreate="Create" />
</components>

Accessor example

Given the following singleton class:

public class SingletonWithAccessor
{
 private static readonly SingletonWithAccessor instance = new SingletonWithAccessor();

private SingletonWithAccessor()
 {
 }

public static SingletonWithAccessor Instance
 {
 get { return instance; }
 }
}

You may expose its instance to the container through the following configuration:

<components>
 <component id="mycomp1"
 type="Company.Components.SingletonWithAccessor, Company.Components"
 instance-accessor="Instance" />
</components>

Using it:

var comp = container.Resolve<SingletonWithAccessor>("mycomp1");

Factory example

Given the following component and factory classes:

public class MyComp
{
 internal MyComp()
 {
 }

...
}

public class MyCompFactory
{
 public MyComp Create()
 {
 return new MyComp();
 }
}

You may expose its instance to the container through the following configuration:

<components>
 <component id="mycompfactory"
 type="Company.Components.MyCompFactory, Company.Components"/>
 <component id="mycomp"
 type="Company.Components.MyComp, Company.Components"
 factoryId="mycompfactory" factoryCreate="Create" />
</components>

Using it:

var comp = container.Resolve<MyComp>("mycomp");

Factory with parameters example

Given the following component and factory classes:

public class MyComp
{
 internal MyComp(String storeName, IDictionary props)
 {
 }

...
}

public class MyCompFactory
{
 public MyComp Create(String storeName, IDictionary props)
 {
 return new MyComp(storeName, props);
 }
}

You may expose its instance to the container through the following configuration:

<components>
 <component id="mycompfactory"
 type="Company.Components.MyCompFactory, Company.Components"/>
 <component id="mycomp"
 type="Company.Components.MyComp, Company.Components"
 factoryId="mycompfactory" factoryCreate="Create">
 <parameters>
 <storeName>MyStore</storeName>
 <props>
 <dictionary>
 <entry key="key1">item1</entry>
 <entry key="key2">item2</entry>
 </dictionary>
 </props>
 </parameters>
 </component>
</components>

Using it:

var comp = container.Resolve<MyComp>("mycomp");

Factory using auto-wire example

If your factory request as parameter some other component instance, this facility will be able to resolve it without your aid:

public class MyComp
{
 internal MyComp(IMyService serv)
 {
 }

...
}

public class MyCompFactory
{
 public MyComp Create(IMyService service)
 {
 return new MyComp(service);
 }
}

You may expose its instance to the container through the following configuration:

<facilities>
 <facility
 id="factorysupport"
 type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.Facilities.FactorySupport"/>
</facilities>

<components>
 <component id="myservice"
 service="SomethingElse.IMyService"
 type="Company.Components.MyServiceImpl, Company.Components" />
 <component id="mycompfactory"
 type="Company.Components.MyCompFactory, Company.Components" />
 <component id="mycomp"
 type="Company.Components.MyComp, Company.Components"
 factoryId="mycompfactory" factoryCreate="Create" />
</components>

Using it:

var comp = container.Resolve<MyComp>("mycomp");

 

Registering components for IoC

Inversion of Control (IoC) is quite a big step for some developers, but the benefits once implemented are huge.  With the applications performance, maintainability, unit testing and more importantly separation of concerns, just to name a few.

Due to the nature and the new concept of IoC to many of the developers, I would strongly recommend that you take some time to go over these two PluralSight course that go into IoC in a lot more detail that we can cover here.   There are other courses that also cover IoC available on PluralSights, but these are the two I would recommend.
Inversion of Control – by John Sonmez
A comprehensive look at inversion of control and how to use common IoC containers
Practical IoC With ASP.NET MVC 4 – by John Sonmez
In this course, we’ll learn how to use an IoC container, like Unity in an ASP.NET MVC 4 application and some of the basics of the practical application of IoC containers.

Basic Registration

The starting point for registering anything in the container is the container’s Register method, with has one or more IRegistration objects as parameter. The simplest way to create those objects is using the static Castle.MicroKernel.Registration.Component class. Its For method returns a ComponentRegistration that you can use to further configure the registration.

Isolate your registration code: It is a recommended practice to keep your registration code in a dedicated class(es) implementing IWindsorInstaller.

Install infrastructure components first: Some components may require a facility or other extension to the core container to be registered properly. As such it is recommended that you always register your facilities, custom subsystems, Component model creation contributors etc before you start registering your components.

To register a type in the container

container.Register(
	Component.For(MyServiceImpl) );

This will register type MyServiceImpl as service MyServiceImpl with default lifestyle (Singleton).

To register a type as non-default service

container.Register(
    Component.For(IMyService).ImplementedBy(MyServiceImpl));

Note that For and ImplementedBy also have non-generic overloads.

// Same result as example above.
container.Register(Component.For(typeof(IMyService))
    .ImplementedBy(typeof(MyServiceImpl))
);

Services and Components: You can find more information about services and components here.

To register a generic type

Suppose you have a IRepository<TEntity> interface, with NHRepository<TEntity> as the implementation.

You could register a repository for each entity class, but this is not needed.

// Registering a repository for each entity is not needed.
container.Register(
    Component.For<IRepository<Customer>>()
        .ImplementedBy<NHRepository<Customer>>(),
    Component.For<IRepository<Order>>()
        .ImplementedBy<NHRepository<Order>>(),
//    and so on...
);


One IRepository<> (so called open generic type) registration, without specifying the entity, is enough.

// Does not work (compiler won't allow it):
 container.Register(
     Component.For<IRepository<>>()
         .ImplementedBy<NHRepository<>>()
 );

Doing it like this however is not legal, and the above code would not compile. Instead you have to use typeof()

// Use typeof() and do not specify the entity:
container.Register(
     Component.For(typeof(IRepository<>))
         .ImplementedBy(typeof(NHRepository<>))
);

Configuring component’s lifestyle

container.Register(
 Component.For<IMyService>()
 .ImplementedBy<MyServiceImpl>()
 .LifeStyle.Transient
);

When the lifestyle is not set explicitly, the default Singleton lifestyle will be used.

Register more components for the same service

You can do this simply by having more registrations for the same service.

container.Register(
    Component.For<IMyService>().ImplementedBy<MyServiceImpl>(),
    Component.For<IMyService>().ImplementedBy<OtherServiceImpl>()
);

When a component has a dependency on IMyService, it will by default get the IMyService that was registered first (in this case MyServiceImpl).

In Windsor first one wins: In Castle, the default implementation for a service is the first registered implementation.

You can force the later-registered component to become the default instance via the method IsDefault.

container.Register(
    Component.For<IMyService>().ImplementedBy<MyServiceImpl>(),
    Component.For<IMyService>().Named("OtherServiceImpl")
        .ImplementedBy<OtherServiceImpl>().IsDefault()
);

In the above example, any component that has a dependency on IMyService, will by default get an instance of OtherServiceImpl, even though it was registered later.

Of course, you can override which implementation is used by a component that needs it. This is done with service overrides.

When you explicitly call container.Resolve<IMyService>() (without specifying the name), the container will also return the first registered component for IMyService (MyServiceImpl in the above example).

Provide unique names for duplicated components: If you want to register the same implementation more than once, be sure to provide different names for the registered components.

Using a delegate as component factory

You can use a delegate as a lightweight factory for a component:

container.Register(
    Component.For<IMyService>()
        .UsingFactoryMethod(
            () => MyLegacyServiceFactory.CreateMyService())
);

UsingFactoryMethod method has two more overloads, which can provide you with access to kernel, and creation context if needed.

Example of UsingFactoryMethod with kernel overload (Converter)

container.Register(
    Component.For<IMyFactory>().ImplementedBy<MyFactory>(),
        Component.For<IMyService>()
            .UsingFactoryMethod(kernel => kernel.Resolve<IMyFactory>().Create())
);

In addition to UsingFactoryMethod method, there’s a UsingFactory method. (without the “method” suffix 🙂 ). It can be regarded as a special version of UsingFactoryMethod method, which resolves an existing factory from the container, and lets you use it to create instance of your service.

container.Register(
    Component.For<User>().Instance(user),
         Component.For<AbstractCarProviderFactory>(),
         Component.For<ICarProvider>()
             .UsingFactory((AbstractCarProviderFactory f) =>
                f.Create(container.Resolve<User>()))
);

Avoid UsingFactory: It is advised to use UsingFactoryMethod, and to avoid UsingFactory when creating your services via factories. UsingFactory will be obsoleted/removed in future releases.

OnCreate

It is sometimes needed to either inspect or modify created instance, before it is used. You can use OnCreate method to do this

container.Register(
   Component.For<IService>()
       .ImplementedBy<MyService>()
       .OnCreate((kernel, instance) => instance.Name += "a")
);

The method has two overloads. One that works with a delegate to which an IKernel and newly created instance are passed. Another only takes the newly created instance.

OnCreate works only for components created by the container: This method is not called for components where instance is provided externally (like when using Instance method). It is called only for components created by the container. This also includes components created via certain facilities (Remoting Facility, Factory Support Facility)

A good source of reference is the Castle Windsor documentation, which can be found here:

https://github.com/castleproject/Windsor/tree/master/docs

Here is a sample project with examples and a MVC application showing how it all works

castle windsor

Lifestyles of the Castle Windsor IoC Containers

It’s worth knowing how the Castle Windsor IoC work, by default it uses Singletons, where this will work for the most of the time, there are a lot more options available to you depending on your needs.  These lifestyles that are available in Castle Windsor are:

  • Singleton: components are instantiated once, and shared between all clients
  • Transient: components are created on demand
  • PerWebRequest: components are created once per Http Request
  • Thread: components have a unique instance per thread
  • Pooled: Optimization of transient components that keeps instance in a pool instead of always creating them
  • Custom: allows you to specify a custom lifestyle… you’d have to specify a type that implements the ILifeStyleManager interface

For further information on this take a look at Castle Windsors Lifestyles or  Windsor and component instance lifetimes

Introduction to Dependency Injection

Dependency Injection (DI) is an incredibly useful and easy technique which makes your code a lot easier to test.

I like to use samples to explain Dependency Injection. We’ll use a SqlMetaDataProvider class which needs to provide the meta data coming from a SQL Server database. It retrieves the meta data from the database in a relational structure (a DataSet) and then converts it to an easy to use object model. Obviously, i want to be able to test this class without actually going to the database because that would make the tests slow. So how can we test if the relational data is being converted to the object model without going to the database?

Well, let’s look at what the class does. First of all, it retrieves sql server meta data. Then it converts it to an object model. But retrieving the meta data doesn’t really belong here… it should be functionality that’s offered by another class. So we create a SqlDataRetriever class. All it will do is return meta data in the relational structure. Nothing more. So now, our SqlMetaDataProvider class can simply use the SqlDataRetriever class to retrieve the meta data. So basically, SqlDataRetriever is now a dependency of the SqlMetaDataProvider class because SqlMetaDataProvider is depending on SqlDataRetriever to return the relational meta data.

At this point, our class could look like this:

    public class SqlMetaDataProvider : IMetaDataProvider
    {
        private readonly string _connectionString;
        private readonly SqlDataRetriever _sqlDataRetriever;
 
        public SqlMetaDataProvider(string connectionString)
        {
            _connectionString = connectionString;
            _sqlDataRetriever = new SqlDataRetriever();
        }
 
        public MetaDataStore GetMetaDataStore()
        {
            SqlMetaData sqlMetaData = _sqlDataRetriever.GetMetaData(_connectionString);
 
            return ConvertToMetaDataStore(sqlMetaData);
        }
 
        private MetaDataStore ConvertToMetaDataStore(SqlMetaData sqlMetaData)
        {
            MetaDataStore store = new MetaDataStore();
 
            AddTablesToStore(sqlMetaData.TableInfo, store);
            AddColumnsToTablesInStore(sqlMetaData.ColumnInfo, store);
            CreateRelationshipsBetweenTables(sqlMetaData.RelationshipInfo, store);
 
            return store;
        }
    }

Note: I left out the code for the AddTablesToStore, AddColumnsToTablesInStore and CreateRelationshipsBetweenTables methods because they aren’t relevant to this specific topic.

Now we need to make sure we can replace the instance of SqlDataRetriever during testing with one we can supply ourselves. That test instance could then simply return a DataSet that was created in-memory, thus keeping our tests running fast. Notice how SqlMetaDataProvider has a reference of the type SqlDataRetriever. The type is essentially fixed, which creates a strong dependency on the SqlDataRetriever class. If we were to replace the type of the reference with an interface, it would at least make it easier to use another type for our required dependency, one that simply implements the interface.

So we create the ISqlDataRetriever interface:

    public interface ISqlDataRetriever
    {
        SqlMetaData GetMetaData(string connectionString);
    }

And then we modify the definition of SqlDataRetriever to implement the interface:

    public class SqlDataRetriever : ISqlDataRetriever

Now we need to modify our SqlMetaDataProvider class so it holds a reference to the interface type, instead of the class type:

        private readonly ISqlDataRetriever _sqlDataRetriever;

We still need to find a way to inject our dependency into our SqlMetaDataProvider so we’ll modify the constructor:

        public SqlMetaDataProvider(string connectionString, ISqlDataRetriever sqlDataRetriever)
        {
            _connectionString = connectionString;
            _sqlDataRetriever = sqlDataRetriever;
        }

The only downside to this is that it now takes more work to create an instance of SqlMetaDataProvider… work that clients shouldn’t need to do if they just want to use the default ISqlDataRetriever implementation. If you’re using an Inversion Of Control (IoC) container, you can simply request an instance of SqlMetaDataProvider and the IoC container would also create the necessary dependency for you. Using an IoC container however is outside of the scope for this post, so we won’t do that. In fact, if you know that your production code will always use the SqlDataRetriever implementation, you could also provide a simpler constructor which takes care of that for you:

        public SqlMetaDataProvider(string connectionString)
            : this(connectionString, new SqlDataRetriever()) {}

So you could use the simpler constructor in your production code, and the other one in your test code. Speaking of test code, we still need to write that test which tests the conversion without hitting the database. First, we need to create an implementation of ISqlDataRetriever which allows us to pass a DataSet to it which the ISqlDataRetriever instance should return to its consumer (our SqlMetaDataProvider):

    public class SqlDataProviderStub : ISqlDataRetriever
    {
        private SqlMetaData _sqlMetaData;
 
        public SqlMetaData SqlMetaData
        {
            set { _sqlMetaData = value; }
        }
 
        SqlMetaData ISqlDataRetriever.GetMetaData(string connectionString)
        {
            return _sqlMetaData;
        }
    }

And finally, the test:

        [Test]
        public void GetMetaDataStore_ProvideDataSetWithTwoTablesAndRelationship_MetaDataStoreIsCorrect()
        {
            SqlMetaData sqlMetaData = PrepareMetaDataSetInMemoryWithTestData();
 
            SqlDataProviderStub sqlDataProvider = new SqlDataProviderStub();
            sqlDataProvider.SqlMetaData = sqlMetaData;
 
            // pass null as the connectionString, and pass our SqlDataProviderStub
            IMetaDataProvider metaDataProvider = new SqlMetaDataProvider(null, sqlDataProvider);
 
            MetaDataStore store = metaDataProvider.GetMetaDataStore();
 
            AssertStoreContainsOurTestData(store);
        }
Original article by Davy Brion

StructureMap Example

After using StructureMap for a while I thought it would be nice to generate a simple example of how it all works, so I’ve built in Visual Studio 2008, both C# and a VB.NET version.

StructreMap Example.zip (4.47 kb)

StructureMapExampleVB.zip (9.41 kb)

For more information on StructureMap please go to their main website

If you need to know more about IoC’s then it’s worth making a look at the following links:

Inversion of Control

List of .NET Dependency Injection Containers (IOC)

IoC Benchmarks

MVC Storefront: Dependency Injection

NinJect