Brussel Airlines have announced that they reduce the velocity of his flies to consume less fuel. Stand to their calculus, if they increase a little bit the duration of their flight the expense to gas up the plane will be reduced by 1,1 Million of Euro per year. In addition to the money ease there will be an ecological benefit for the reduced emission of gas.

Last week I went to a customer that is about to release a quite big web application composed by various modules and services. I worked with them to resolve some issues and close the development cycle.

The thing that let me a little bit disappointed is the way they work: they don’t have unit tests (and this sadly, in Italy, is quite normal) so to “test” the application they have to run it and navigate to the interested page.

The problem is that from the moment that I press F5 it takes about 2 minutes to the moment that the Login page is available, to this adds a bunch of seconds to do the login and another bunch to arrive to  the page that I want to test (in total about 3 minutes).

Let’s do some computation:

They are in the final phase of development so they do little modifications to the code and some bug fixing, so the F5 key is pressed a lot of times during the day, let’s say 50-60 times a day. So:

3 minutes * 50 times = 150 minutes = 2,5h

This mean about 2,5 hours a day spent in doing nothing

Without introducing unit tests that in this final stage will be a loss of time, what about a script that speed-up the Build&Run phase? And maybe an “#ifdef debug” then don’t ask me for username and password but go directly to  the home page? And if we take off from the main solution the projects that are not subjected to modification? And if we will do pair programming so I can avoid to press F5 if my pair see that I make a visible mistake?

These are only some of little actions that helps the team to save some seconds at every debug session, that in a day will be hours! 

Most of us know Windsor Castle the (most?) famous IoC container. Not everybody knows that you can use Castle with some extensions (facility) useful in some circumstances.

I would like to talk about the Factory Support.

The default mode for an object registered in the configuration file to be constructed is by the new operator that calls the constructor in which, if necessary, the container inject the parameters. But sometimes we need to create an object using a factory class.

Castle support this construction mode using the Factory Support Facility that means configure it in the right way. Suppose that you need to use Windsor container to get an instance of an NHibernate Session, that, like you know, it cannot be created using the new operator but it must be constructed using a SessionFactory class.

Sometimes this SessionFactory is encapsulated in a NHibernateHelper class:

public static class NHibernateHelper
{
    private static readonly ISessionFactory sessionFactory;

    static NHibernateHelper()
    {
        Configuration cfg = new Configuration();
        cfg.Configure();
        sessionFactory = cfg.BuildSessionFactory();
    }

    public static ISession GetNewSession()
    {
        return sessionFactory.OpenSession();
    }

    // ...
}

This class has a static method GetNewSession that return a new instance of ISession. I want to use this class (and the GetNewSession method) to obtain the session using the IoC container and I want to inject this session in a repository:

public class UserRepository : IUserRepository
{
    public UserRepository(ISession session)
    {
        //...
    }
}

The only things that I need to do is to configure Castle in this way:

<castle>
    <facilities>
        <facility id="factorysupport" type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.Microkernel" />
    </facilities>
    <components>
        <component id="session"
            type="NHibernate.ISession, NHibernate"
            factoryId="sessionFactory"
            factoryCreate="GetNewSession" />

        <component id="sessionFactory"
            type="NHibernateHelper, CodicePlastico.Samples" />

        <component id="userRepository"
            service="CodicePlastico.Samples.Repositories.IUserRepository, CodicePlastico.Samples"
            type="CodicePlastico.Samples.UserRepository, CodicePlastico.Samples" />
    </components>
</castle>

The first block (facilities) add to Windsor the necessary support to use the factory facility after that there’s the components registration:

The first (session) is the object that will be created using a factory, I specified the type (ISession) and the Id of the component that works as a factory (sessionFactory) and the method (factoryCreate) that should be called for the construction of ISession (GetNewSession).

Obviously you must register the factory class (sessionFactory component) and the IUserRepository (userRepository) using the usual syntax.

What happen when I request an object of type IUserRepository?

The container sees that the concrete type is UserRepository and see that the constructor receive an instance of ISession. Then it goes to see how to build an ISession object, and see that it needs to use the GetNewSession method of NHibernateHelper.

This is a quite useful technics to use when you cannot use the constructor to build an object but still want to use an IoC container.