I need your help.
Does it make sense to have something like this in a DI container?

[Fact]
public void CanSupplyFactoryMethod()
{
    store.Register(
        p => p.Service<IService>()
                 .Factory(s => 
                     {
                         Console.WriteLine("Creating type..");
                         if (SOME_STATIC_VAR == true)
                         {
                             return new ClassWithNoDependencies();
                         }
                         return new OtherClass();
                     })
        );
    var service = container.Resolve<IService>();
    Assert.IsType<ClassWithNoDependencies>(service);
}

The idea being, you can supply a function delegate (Func<IPandoraContainer, T>) to be executed when the service should be instantiated. This would make a rather interesting extensibility story, since I’d avoid having to build in all kinds of hard to find hooks to allow modification of the object creation.

Also, I’d like this delegate to be evaluated during runtime. This could enable me to resolve to another object if for example a network link is down etc.

Another obvious use for this would be to access classes that are present in the .NET BCL but can’t be instantiated and would otherwise be supplied to the container through .Instance like the HttpContext:

store.Register(
    p => p.Service<HttpContext>()
        .Factory(s => { return HttpContext.Current; }));

What do you think? Should this make it into Pandora? What do you want to see in a DI container? Please feel free to comment.

Yesterday I finished expanding the Pandora wiki a bit on how to configure the container and while doing so I made one discovery:

I never tested if Pandora can handle generic types!!

Wow, why didn’t I think about that. One of the most important scenarios fully untested. Thank god, simple generic registration already worked:

[Fact]
public void CanResolveSpecificGenericClass()
{
    store.Register(p => 
        p.Service<GenericClass<string>>()
        .Implementor<GenericClass<string>>());

    Assert.DoesNotThrow(() => container.Resolve<GenericClass<string>>());
}

The moment you define what generic type you are using, a generic class is just a regular class that can be used like all the others.

Still, it sucks having to specify one class explicitly 5 times if I want 5 to use it with 5 types. So I set out to support the following scenario:

[Fact(Skip = "Not implemented yet")]
public void CanRegisterAndResolveRealGenericRequests()
{
    store.Register(p => 
        p.Generic(typeof(GenericClass<>))
        .Implementor(typeof(GenericClass<>))
        .ForAllTypes());

    Assert.DoesNotThrow(() => {
        var resolve = container.Resolve<GenericClass<string>>();
    });
}

I want the container to just know the generic and then figure out if the generic registration can satisfy my requested service. Since this would obviously require Reflection in the resolving part of Pandora, I shelved that feature for a maybe more useful one that at least eases some of the generic pain:

store.Register(
    p => p.Generic(typeof (GenericClass<>))
             .Implementor(typeof (GenericClass<>))
             .OnlyForTypes(typeof (string), typeof (int)));

This way I can specify in one registration what types I want the generic to serve and the Fluent interface will create a distinct registration for each type in .OnlyForTypes[]. This way I don’t need any reflection code in the resolving part of Pandora.
And: It’s already implemented.

You can find the source to Pandora at the project website on Bitbucket.

There are times when your services depend on an object you can’t construct yourself. One obvious example being the HttpContext in most ASP.NET applications.

So all DI containers have some way to inject an instance into the container to cover that. Pandora has joined them yesterday. It’s baked into the fluent interface and the ComponentStore:

Fluent:

var store = new ComponentStore();
            var instance = new ClassWithNoDependencies();
            store.Register(p => p.Service<IService>("test")
                                    .Instance(instance));

Conventional:

var store = new ComponentStore();
            var instance = new ClassWithNoDependencies();
            store.AddInstance<IService>(instance);

It’s amazing how much smarter you can become by simply looking at other people’s code. So, today I spent almost half the morning looking at different test frameworks from the TDD/BDD world looking for cool tricks I haven’t thought of (I examined MSpec, NBehave, NSpec and xUnit). One of those interesting little tricks (trivial at best, but valuable) is the following I found in xUnit’s Guard.cs:

Guard class, used for guard clauses and argument validation

Imagine the following method:

public bool Authenticate(string username, string password)
{
    return username == "daniel" && password == "tigraine";
}

Let’s say my specification for this method says: “input username and password can’t be null and should return a ArgumentNullException”. Reasonable, since we never trust input. So, usually I’d create guard clauses at the top of my method to protect me from said bad input:

public bool Authenticate(string username, string password)
{
    if (username == null)
        throw new ArgumentNullException(username);
    if (password == null)
        throw new ArgumentNullException(password);

    return username == "daniel" && password == "tigraine";
}

I always thought about this as rather readable and nice to work with, until I saw what xUnit did in Guard.cs, allowing me to shorten the above to a simple:

public bool Authenticate(string username, string password)
{
    Guard.ArgumentNotNull("username", username);
    Guard.ArgumentNotNull("password", password);

    return username == "daniel" && password == "tigraine";
}

I still believe this can be improved upon, maybe making it only one argument instead of two, but for now this is way better than what I used to write before.

Brad Wilson left me an inspiring comment on my post about his Guard class that I immediately tried out:

If you target 3.5, you could write a guard which used expressions, and then you could evaluate the expression in order to fill things out. Unfortunately, the syntax ends up a little wonky, but at least you’re not repeating yourself:

Guard.ArgumentNotNull(() => username);

You could also do the same thing with complex expressions:

Guard.Precondition(() => username.Length > 10);

and when you throw the exception, it can even contain the actual condition code, extracted from the expression.

I went off to implement this using an Expression and ended up with the following ArgumentNotNull method:

public static void ArgumentNotNull(Expression<Func<object>> action)
{
    var result = action.Compile()();
    if (result == null)
    {
        //TODO: Extract memberinfo name from expression
        throw new ArgumentException();
    }
}

One thing to keep in mind is that guard clauses usually end up being in production code, and not in test code. So performance isn’t neglect able. Since action.Compile() clearly indicates that some compiling overhead happens to retrieve the value, I thought it might be interesting to benchmark it. Just in case it might still be neglect able.

So, I wrote the following tester:

using System;
using System.Diagnostics;
using System.Linq;

public class Program
{
    private static int passes = 10000;
    private static void Main(string[] args)
    {
        var runs = 5;
        Console.WriteLine("{0} ms to run normal", AverageExecutionTime(RunSimple, runs));
        Console.WriteLine("{0} ms to run with expression", AverageExecutionTime(RunExpressions, runs));
        Console.ReadLine();
    }
    private static long AverageExecutionTime(Action delegateToWatch, int runs)
    {
        var lapTimes = new long[runs];
        for (var i = 0; i < runs; i++)
        {
            lapTimes[i] = GetExecutiontime(delegateToWatch);
        }
        return lapTimes.Sum(p => p)/runs;
    }
    private static long GetExecutiontime(Action delegateToWatch)
    {
        var stopwatch = new Stopwatch();
        stopwatch.Start();
        delegateToWatch();
        stopwatch.Stop();
        return stopwatch.ElapsedMilliseconds;
    }
    private static void RunSimple()
    {
        for (int i = 0; i < passes; i++)
        {
            string user = "test";
            Guard.ArgumentNotNull("user", user);
            GC.Collect();
        }
    }
    private static void RunExpressions()
    {
        for (int i = 0; i < passes; i++)
        {
            string user = "test";
            Guard.ArgumentNotNull(() => user);
            GC.Collect();
        }
    }
}

As you can see, I rerun the test 4 times doing the NotNull test only 10000 times (always running the non-exceptional path), always forcing garbage collection between passes.

The results were stunning:

I ran the test on my 2x3.16 Ghz Intel with 8gb Ram running Windows Vista x64 with no debugger attached and it turned out the expression tree compilation took almost 1 ms per pass. (Without garbage collection normal runs took 0 ms)

Now one could argue, no sane person would place those guards inside some tight loop. But once you run into recursive method calls you may end up creating a performance bottleneck.

Now, since I’m a lazy guy, I ended up writing a Resharper Live template that saves me the repetitive typing:

Guard.ArgumentNotNull("$parametername$", $parametername$);
$END$

I just finished refactoring Pandora to have a much cleaner configuration and also to enable lifestyles for certain components.

Until now, Pandora was not able to save one service after it’s initial activation. Every call to container.Resolve() would instantiate a new service with new dependencies etc. It may be of interest to some of you that this is the exact opposite of the default lifestyle Windsor sets for it’s components. So I obviously wanted to change that.

[Fact]
public void ActivationHappensOnlyOnceForSingletonComponents()
{
    var store = new ComponentStore();
    var registration = store.Add<IService, ClassWithNoDependencies>("test");
    registration.Lifestyle = ComponentLifestyles.Singleton;

    var container = new PandoraContainer(store);
    var service = container.Resolve<IService>("test");
    var service2 = container.Resolve<IService>("test");
    Assert.Same(service, service2);
}

All “logic” concerning a lifestyle is completely enclosed in the Lifestyle classes so creating a new lifestyle for Pandora should be rather simple in the future.

But the real big news (and the real big change) is the changed configuration.
At first I tried to bake a fluent interface into the Registration (the class Pandora uses to represent one registered service) to allow nice parameter syntax.

The idea was good, but it led to some problems with the interface and also made it much harder to consume those registrations inside the container.

I then decided to rip everything out and revert the registration to a dumb value type that only holds information that can be easily serialized/deserialized if needed.
So that the fluent interface would generate a value type, instead of trying to be one with all it’s faults. Doing so opened up a whole lot of new possibilities in terms of API for me, and so I ended up with a quite pleasant interface like this:

store.Register(p => p.Service<IService>("db.service")
                        .Implementor<ClassWithNoDependencies>()
                        .Parameters("hello").Set("world")
                        .Lifestyle.Transient()
                        .Parameters("foo").Set("bar"));

As before, this looks intentionally familiar to Windsor users, since I believe Windsor’s interface is really good and makes a lot of sense when reading.
What I improved upon (at least, I believe so) was to get away from the static Component class Windsor uses to bootstrap the Fluent registration, but to use a closure that provides Intellisense right from the beginning.

Meaning, in Windsor there is no Intellisense when you Write: container.Register() .. From the signature you can only see that you need an array of IRegistration while nobody tells you that you need to use that static class that’s buried down in Castle.MicroKernel.Registration, while writing p. instantly brings up all registration options in Pandora.

Next in line is improving the fluent interface even further to allow for auto-configuration (eg. take Assembly A and register all Types in there).

Another challenge I want to tackle with Pandora is externalizing the configuration. Fluent interfaces are awesome for developers (since they allow easy refactoring), but the real power of a DI container also comes from the ability to change the configuration without recompiling the app. Usually all containers solve this through XML, so I’d like to try a new approach here and am currently thinking about making Pandora read the configuration from a IronPython script. That would allow me to consume the Fluent Interface without recompiling the application and paying the XML bracket tax while retaining the flexibility of just opening up a text file to change my configuration.

As usually, you can find the source to Pandora at the project website on Bitbucket.

In case you haven’t heard. Some time ago Microsoft sat with most authors of leading IoC containers and defined a common interface for Dependency Injection / Service Location. You can get all the relevant information about the Common Service Locator through reading Glenn Block, Ayende Rahien or Chris Travares and you can download it from it’s Codeplex site. There is a comprehensive API reference in their wiki too.

Ayende sums the purpose of the CSL up pretty well:

The idea is based off a post that Jeremy Miller had about a month ago, having a common, shared interface across several IoC implementation. That would allow library authors to make use of the benefits of a container without taking a dependency on a particular implementation.

The alternative for that is to each library to create its own abstraction layer. A good example of that is NServiceBus' IBuilder interface, or ASP.NET MVC's IControllerFactory. That is just annoying, especially if you are integrating more than a single such framework.

In Pandora I aimed for CSL compliance from the beginning, and the CSLAdapter class has been there for quite some time now. But since Pandora only recently got the named lookups feature I never finished it.

Until now. Today I finally implemented the CommonServiceLocatorAdapter that (for me) somehow “verifies” that Pandora supports most mandatory lookup features needed from a DI container.

On the implementation side: I first tried to implement IServiceLocator directly, until I discovered the abstract ServiceLocatorImplBase class that wraps all of the overloads and generic/nongeneric stuff, saving you a bunch of boilerplate code.

Coming up next in Pandora will be component lifestyles, forwards and then maybe DLR configuration.

One rather essential feature for a DI container is to be able to lookup components by some key. For example retrieving a specific IController class based on the controller name specified by the request.

So the usual use case for the above looks like this:

var store = new ComponentStore();
store.Add<IRepository, MemoryRepository>("memory.repository");
store.Add<IRepository, SqlRepository>("db.repository");
var container = new PandoraContainer(store);

var service = container.Resolve<IRepository>("db.repository");

Now, there is another thing too: What if I want one controller to use one special repository out of the registered ones:

var store = new ComponentStore();
store.Add<IRepository, SqlRepository>("db.repository");
store.Add<IRepository, MemoryRepository>("memory.repository");
store.Add<Controller, Controller>()
    .Parameters("repository").Eq("memory.repository");
var container = new PandoraContainer(store);

var controller = container.Resolve<Controller>();

Well, yes Pandora can do those kinds of things too.

If you know Windsor’s Fluent interface .Parameters().Eq() may sound familiar to you. That’s intentionally. I like the Windsor Fluent syntax.

What I really underestimated was how to do the fluent interface. It’s not terribly hard, but it’s takes some tinkering ;).

You can find the source to Pandora at the project website on Bitbucket.