Brighton ALT.NET Beers. 7pm Tuesday 1st June at The Skiff

The next Brighton ALT.NET Beers will be held at the co-working venue ‘The Skiff’ at 7.00 pm on Tuesday 1st June. I’ll be hosting again.

The address is: The Skiff, 49 Cheltenham Place, Brighton, BN1 4AB

View Larger Map

The format will be the same as usual, a quick round of suggestions for topics, voting and then an evening of beer and geekery.

What better way to recover from the rigours of the bank holiday weekend?

Skillsmatter Progressive .NET Tutorials May 12-14th 2010

This week I had the pleasure of talking at the second Progressive .NET Tutorials organised by Skillsmatter in London. I presented a four hour workshop on advanced Castle Windsor. You can watch the videos here:
Part 1
Part 2
Part 3

You can get the code from my Google Code repository here.

To be honest, I’ve been getting quite bored of being ‘windsor-man’ in the UK alt-net community and after the last time I presented my ‘introduction to IoC’ talk, I vowed I would never do it again. But doing this workshop was a lot of fun. Having four hours to get to grips with some more advanced topics was really nice. It helped that I had a very keen audience who asked some great questions and really got involved. It was also interesting to see some of the common misconceptions and problems people have with IoC containers. It seems that most confusion comes from deciding what should come out of a container and what should not. This often manifests itself in questions about factories and how you should resolve things like domain entities, or how you should do resolution within them. The simple answer is you don’t, but it’s difficult to explain what is an appropriate ‘service’ and what is not. It’s something I’m still struggling with.

I only attended the Wednesday session. I had intended to attend on Friday as well, but my teeth decided otherwise and I spent the morning in my dentist’s chair instead. So the only other session I got to see was Robert Pickering’s introduction to F# and even though I saw him do a similar talk last year, I still found it very interesting and learnt a whole load of stuff about F# that I didn’t know before.

Wendy, Skillsmatter’s boss, took all the speakers out to dinner and I had a great evening chewing things over with Dave Laribee, Scott Cowan, Toby Henderson, Ayende and Ian Cooper. But probably the most significant revelation of the day was that I finally discovered the true identity of prolific tweeter @Daneel3001 :)

10 Advanced Windsor Tricks – 13. Use SubContainers to replace dependencies on context

Here’s part thirteen of (slightly more than) 10 Advanced Windsor Tricks.

Say you have a multi-tenanted application and you want to have different components provided for different customers. One way of doing this is to create an IHandlerSelector which allows you to choose which components get provided depending on some context. It’s the technique I use for Suteki Shop’s multi-tenancy and I’ve written about it several times in the past: here and here.

An alternative approach is to use a SubContainer. SubContainers are a way to provide separate scoping and resolution, independent of your main container. In this scenario (described here by Bill Pierce) you provide a SubContainer for each tenant, and simply register the components that that tenant needs that are different from the default.

Here’s a simple demonstration:

public void SubContainer_should_get_components_of_parent()
{
    var parentContainer = new WindsorContainer()
        .Register(
            Component.For<Root>().LifeStyle.Transient,
            Component.For<ChildNode>().LifeStyle.Transient,
            Component.For<IGrandChild>().ImplementedBy<GrandChild>().LifeStyle.Transient
        );

    var subContainer1 = new WindsorContainer()
        .Register(
            Component.For<IGrandChild>().ImplementedBy<FirstGrandChild>().LifeStyle.Transient
        );

    var subContainer2 = new WindsorContainer()
        .Register(
            Component.For<IGrandChild>().ImplementedBy<SecondGrandChild>().LifeStyle.Transient
        );


    parentContainer.AddChildContainer(subContainer1);
    parentContainer.AddChildContainer(subContainer2);

    var parentRoot = parentContainer.Resolve<Root>();
    parentRoot.Accept(node => Console.WriteLine("Resolved from parent container: {0}", node.GetType().Name));

    var child1Root = subContainer1.Resolve<Root>();
    child1Root.Accept(node => Console.WriteLine("Resolved from subContainer1: {0}", node.GetType().Name));

    var child2Root = subContainer2.Resolve<Root>();
    child2Root.Accept(node => Console.WriteLine("Resolved from subContainer2: {0}", node.GetType().Name));
}

Which outputs:

Resolved from parent container: Root
Resolved from parent container: ChildNode
Resolved from parent container: GrandChild
Resolved from subContainer1: Root
Resolved from subContainer1: ChildNode
Resolved from subContainer1: FirstGrandChild
Resolved from subContainer2: Root
Resolved from subContainer2: ChildNode
Resolved from subContainer2: SecondGrandChild

I’m creating a parent container and registering three components, Root, ChildNode and IGrandChild. Root depends on ChildNode and ChildNode depends on IGrandChild. I then create two subContainers and register alternative IGrandChild components for each.

I’ve got a little visitor pattern thing going to run some function over each object in the graph so that I output the component types.

When I resolve Root from the parent container, I simply get an object graph with IGrandChild implemented by GrandChild. So my default implementation works as expected.

The really cool stuff happens when I resolve Root from the sub containers. Root is not registered with the sub containers, so they resolve it from their parent (parentContainer). The same goes for ChildNode. But the IGrandChild dependency is satisfied by the sub container’s registration. With this technique you can surgically replace specific dependencies.