Entries tagged 'ioc' ↓

The shiny new system which I’ve recently been developing makes heavy use of the Chain of Responsibility pattern, and as such a number of service classes take an array of objects in the constructor:

/// <summary>
/// Initializes a new instance of the LeadAllocationService class.
/// </summary>
/// <param name="leadAllocators">Array of Lead Allocators.</param>
public LeadAllocationService(params ILeadAllocator[] leadAllocators)
{
    this.LeadAllocators = leadAllocators;
}

I’m using Castle Windsor for dependency management, so I’ve been fluently registering all instances of ILeadAllocator:

container.Register(
    AllTypes
    .Of<ileadallocator>()
    .FromAssemblyNamed("Marshalls.Leads.ApplicationService")
    .WithService
    .FromInterface(typeof(ILeadAllocator))
    .Configure(c => c.LifeStyle.Transient));

Easy, right? And yet at runtime Windsor surprised me by throwing this exception in my face:

Castle.MicroKernel.Handlers.HandlerException: Can't create component 'Marshalls.Leads.ApplicationService.LeadAllocationService' as it has dependencies to be satisfied.
Marshalls.Leads.ApplicationService.LeadAllocationService is waiting for the following dependencies:
Keys (components with specific keys)
- leadAllocators which was not registered.

Huh?! What gives? Well, a little Googling revealed this post from Castle founder Hamilton Verissimo explaining that by default the Castle MicroKernel expects me to define what should be included in the array. But he goes on to explain that the behaviour I desire can be achieved by registering a custom subresolver with the microkernel. That subresolver has since been included in the Castle Windsor distro, so in actual fact all I needed to do was add the following line of code when configuring my container:

container.Kernel.Resolver.AddSubResolver(new ArrayResolver(container.Kernel));

So now, when new implementations of ILeadAllocator are added to the codebase, they are immediately available to the CofR pattern within the LeadAllocationService, with no additional work required by the developer. Hurrah!

I always knew my lifestyle choices would come back to bite me some day…

I’ve been making heavy use of the Castle Windsor container to handle dependency and configuration management in the shiny new system that I’m currently developing. For the most part it’s been an absolute blast, allowing me to easily create a loosely-coupled system architecture and focus my efforts on what the system should be achieving for the client, rather than worrying about how it all hangs together.

But recently I encountered a bit of a gotcha which made me think that perhaps I should spend some more time understanding exactly what Windsor is doing in the background.

See, it turns out that the default lifestyle for components registered with Windsor is Singleton. So, every time I asked Windsor for an IFooRepository, it supplied me with exactly the same concrete instance of FooRepository. Which would have been fine if it weren’t for the fact that FooRepository happened to indirectly hold a private reference to a thread-afine NHibernate session context. Ouchy.

The system I’m developing is a WCF service, and I’m using a Unit of Work pattern to open an NH session before the operation is invoked, and close it afterwards. To make this work, I simply needed to make sure that FooRepository (and any Castle-fulfilled component which has an IFooRepository dependency) has a transient lifestyle. Indeed, on further reflection, for most of the systems I develop, the transient lifestyles should be my default choice, and I do wonder why the Windsor developers chose to make singleton the default.

Davy Brion has more info on this topic in this blog post – Windsor and Component Instance Lifetimes.

So, moral of the story – understand how your IoC container is fulfilling your requests, and be prepared to specify non-default behaviours if necessary. Convention over configuration is only a benefit if you’re happy with the conventions.

I spent much of this weekend over in Bradford, talking shop with the good folks at the Alt.Net UK ‘in the North’ conference. I had a great time, learned much, and am grateful to Richard Fennell of Black Marble and the other organisers and sponsors for making the event possible.

This was the first Open Spaces event I’ve attended, and I was pleasantly surprised at how orderly and productive the sessions turned out to be. Unlike conventional sales-pitch conferences of the MSDN roadshow variety, this was more of an open forum, with an expectation that all of the relatively small number (25ish?) of participants would, well, participate!

I was also surprised to find that there were more pragmatists in attendance than architecture astronauts. Maybe it’s a reflection of the current economic climate, but a common theme was on finding toolings that were good enough with which to deliver suitable solutions quickly and effectively, rather than striving for architectural purity and perfection.

It was great to hear some war stories, and learn about technologies, tools, methodologies and ideas that are currently exciting other people. It would be difficult to come away from a weekend like this one without some inspiration and a big list of several things to follow up on. Here’s mine:

• MVC Framework – like myself, a lot of the attendees have had enough of the WebForms model, and are excited about the potential of ASP.NET MVC.
• Fluent NHibernate – it sounds like the project being feverishly worked on by James Gregory et al is ready for prime time. People spoke very positively of the ability to ditch XML HBM files in favour of this strongly-typed configuration.
• Balsamiq Mockups – loved by everyone, even despite (or should that be because of?) its use of Comic Sans MS!
• Inversion of Control – there was a wide mix of IoC containers being used. I’ve tried Castle Windsor, other people made positive murmurings about Unity and StructureMap.
• TypeMock Isolator – apparently capable of mocking the unmockable.
• Sketching User Experiences – everyone who’d heard of him spoke highly of Bill Buxton’s work.
• Open Quarters CMS – a great demonstration of a CMS built on ASP.NET MVC by Anthony Main and Andrew Magee. I look forward to taking a squizz at the source, I’m sure it will be an excellent learning aid.
• SWAT – a web testing tool developed by some folks at Ultimate Software and released on Sourceforge as an open source project (thanks to Nick for the link).
• Wild Blue Yonder – a delicious amber ale from Oregon which was on tap at the Sir Titus Salt pub, to where we decamped after the planning session on Friday night. Yum!

I’m probably forgetting some things, there was a lot to take in, and I regret not having a pad of paper on hand. Hopefully my memory will be jogged by the blog postings of the other attendees.

Thanks again to all who made it possible, and all the attendees for quality the chat and inspiration.