I finally decided it’s time to release Pandora. The current build is stable and meets all of my current requirements, so I feel the best way to advance Pandora is to dogfood it on another project.

Also, this gives me a bit of an opportunity to catch up on the documentation side of things and work out bugs that may be there.

Upcoming features

I still have a pretty interesting wish list (Generics, Factory Methods, AutoConfiguration), but those features are all rather non-trivial and I feel Pandora should stay a simple and minimalistic container right now.

Where to get

You can download the compiled Pandora release from Bitbucket or you can grab the source and compile it for yourself.

Compiling Pandora

Just run the build.bat script and NAnt (supplied within the repository) will fire up and compile everything into the build\ directory. By default the script will also compile and run the accompanying unit tests, leaving you with a Pandora.Test-Result.htm file you can then review if you please.

To compile without tests simply run “build compile”, and you’ll end up only with Pandora.dll/pdb and the common service locator library.

Using Pandora

If you didn’t run build compile, you end up with lots of stuff in your build directory:

If you plan on using Pandora you only need the following:

If you are interested in the ServiceLocation.dll you can read about it here: Common Service Locator Adapter for Pandora

I guess this screen will look really odd to non-programmers using the awesome Twitter client blu:

The text in the box says:

The value for a Int32 was too big or too small.

Oh, and we all knew this is coming, thanks to http://www.twitpocalypse.com/

While trying out some WPF, I ended up downloading this code sample on Drag&Drop that contained the following piece  of code:

if (e.Source == MyCanvas)
{
}
else
{
    _isDown = true;
    _startPoint = e.GetPosition(MyCanvas);
    _originalElement = e.Source as UIElement;
    MyCanvas.CaptureMouse();
    e.Handled = true;
}

Come on? I’ve seen 6 year olds that knew the use of != and ==.

Please Microsoft: Documentation is as important as shipping code. At least review what crap is getting put out there. It just looks bad to say the least.

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.

I’ve spent the last two days working on true generic registrations inside Pandora to enable scenarios like this:

[Fact]
public void CanResolveRealGenericAsSubdependency()
{
    store.Register(p =>
                       {
                           p.Service<IService>()
                               .Implementor<ClassDependingOnGenericClass>();
                           p.Generic(typeof (GenericClass<>))
                               .Implementor(typeof (GenericClass<>))
                               .ForAllTypes();
                       });
    Assert.DoesNotThrow(() => container.Resolve<IService>());
}

Well, if you look at the last changeset, I apparently succeeded for the above example, but decided to revert the changes and start over fresh. Generics are a difficult topic to tackle, and the current implementation feels too much like a hack to me.

But there are some things this failed experiment has taught me:

First: Generic types are just Types. And there are two subclasses of them:

1. GenericTypeDefinition – This one represents the generic with no supplied type argument. Eg: typeof(Service<>)  Cannot be activated.
2. GenericType – Represents the final type that can be treated like a normal type. Eg: typeof(Service<string>)

So, how do you tell those 3 apart (the third being a normal non-generic)?
Simple: Both generic types have the IsGenericType property set to true and GenericTypeDefinition also has IsGenericTypeDefinition set to true.

If you are faced with a GenericType, you can always extract the GenericTypeDefinition by calling GetGenericTypeDefinition() (very useful if you try to compare types in some scenarios).

The inverse can also be done (creating a GenericType from a definition) by calling MakeGenericType():

var type = typeof (string);
Type genericType = typeof (GenericClass<>).MakeGenericType(type);

And, in case you want to know what the argument type (T part) of a generic type is you can use the GetGenericArguments() method to find out:

[Fact]
public void ExtractGenericArgumentType()
{
    var type = typeof (SuperGeneric<string, int, long, float>);
    Type[] arguments = type.GetGenericArguments();
    foreach (var argument in arguments)
    {
        Console.WriteLine(argument.Name);
    }
}

The above produces the following:

String
Int32

Int64

Single

Ps: Try this stuff out for yourself! Reflection is real fun and surely helped me understand some things better. Don’t let yourself be thrown off by comments like “Reflection is too slow, never use it” etc.. Reflection and dynamic activation can make your life much easier if you know how to use it!

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);

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$

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.

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.