How to use Rebus in a web application

2015-08-21 by mookid8000 8 Comments

If you’re building web applications, you will often encounter situations where delegating work to some asynchronous background process can be beneficial. Let’s take a very simple example: Sending emails!

We’re in the cloud

Let’s say we’re hosting the website in Azure, as an Azure Web Site, and we need to send an email at the end of some web request. The most obvious way of doing that could be to new up an SmtpClient with our SendGrid credentials, and then just construct a MailMessage and send it.

While this solution is simple, it’s not good, because it makes it impossible for us to have higher uptime than SendGrid (or whichever email provider you have picked). In fact, every time we add some kind of synchronous call to the outside from our system, we impose their potential availability problems on ourselves.

We can do better 🙂

Let’s make it asynchronous

Now, instead of sending the email directly, let’s use Rebus in our website and delegate the integration to external systems, SendGrid included, to a message handler in the background.

This way, at the end of the web request, we just do this:

await _bus.Send(new SendEmail(recipient, subject, body));

1	await _bus.Send(new SendEmail(recipient, subject, body));

and then our work handling the web request is over. Now we just need to have something handle the SendEmail message.

Where to host the backend?

We could configure Rebus to use either Azure Service Bus or Azure Storage Queues to transport messages. If we do that, we can host the backend anywhere, including as a process running on a 386 with a 3G modem in the attic of an abandoned building somewhere, but I’ve got a way that’s even cooler: Just host it in the web site!

This way, we can have the backend be subject to the same auto-scaling and whatnot we might have configured for the web site, and if we’re a low traffic site, we can even get away with hosting it on the Free tier.

Moreover, our backend can be Git-deployed together with the website, which makes for a super-smooth experience.

How to do it?

It’s a good idea to consider the backend a separate application, even though we chose to deploy it as though it was one. This is just a simple example on how processes and applications are really orthogonal concepts – in general, it’s limiting to attempt to enforce a 1-to-1 between processes and applications(*).

What we should do is to have a 1-to-1 relationship between IoC container instances and applications, because that’s what IoC containers are for: To function as a container of one, logical application. In this case that means that we’ll spin up one Windsor container (or whichever IoC container is your favorite) for the web application, and one for the backend. In an OWIN Startup configuration class, it might look like this:

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        ConfigureWebApi(app);

        ConfigureBackend(app);
    }

    static void ConfigureWebApi(IAppBuilder app)
    {
        var httpConfiguration = new HttpConfiguration();
        WebApiConfig.Register(httpConfiguration);

        var webContainer = new WindsorContainer()
            .Install(new ApiHandlerInstaller())
            .Install(new WebRebusInstaller());

        httpConfiguration.UseWindsorContainer(webContainer);

        app.RegisterForDisposal(webContainer, "Windsor container for the web app");

        app.UseWebApi(httpConfiguration);
    }

    void ConfigureBackend(IAppBuilder app)
    {
        var backendContainer = new WindsorContainer()
            .Install(new RebusHandlerInstaller())
            .Install(new BackendRebusInstaller());

        app.RegisterForDisposal(backendContainer, "Windsor container for the background jobs");
    }
}

public class Startup

{

public void Configuration(IAppBuilder app)

{

ConfigureWebApi(app);

ConfigureBackend(app);

}

static void ConfigureWebApi(IAppBuilder app)

{

var httpConfiguration = new HttpConfiguration();

WebApiConfig.Register(httpConfiguration);

var webContainer = new WindsorContainer()

.Install(new ApiHandlerInstaller())

.Install(new WebRebusInstaller());

httpConfiguration.UseWindsorContainer(webContainer);

app.RegisterForDisposal(webContainer, "Windsor container for the web app");

app.UseWebApi(httpConfiguration);

}

void ConfigureBackend(IAppBuilder app)

{

var backendContainer = new WindsorContainer()

.Install(new RebusHandlerInstaller())

.Install(new BackendRebusInstaller());

app.RegisterForDisposal(backendContainer, "Windsor container for the background jobs");

}

In the code sample above, UseWindsorContainer and RegisterForDisposal are extension methods on IAppBuilder. UseWindsorContainer replaces Web API’s IHttpControllerActivator with a WindsorCompositionRoot like the one Mark Seemann wrote, and RegisterForDisposal looks like this:

public static void RegisterForDisposal(this IAppBuilder appBuilder, IDisposable disposable, string description = null)
{
    var descriptionOfDisposable = description ?? disposable.ToString();

    var context = new OwinContext(appBuilder.Properties);
    var token = context.Get<CancellationToken>("host.OnAppDisposing");
    if (token == CancellationToken.None)
    {
        Trace.TraceInformation("{0} could not be registered for disposal because the cancellation token could not be found", descriptionOfDisposable);
        return;
    }

    Trace.TraceInformation("Registering for disposal: {0}", descriptionOfDisposable);

    token.Register(() =>
    {
        Trace.TraceInformation("Disposing {0}", descriptionOfDisposable);

        disposable.Dispose();
    });
}

public static void RegisterForDisposal(this IAppBuilder appBuilder, IDisposable disposable, string description = null)

{

var descriptionOfDisposable = description ?? disposable.ToString();

var context = new OwinContext(appBuilder.Properties);

var token = context.Get<CancellationToken>("host.OnAppDisposing");

if (token == CancellationToken.None)

{

Trace.TraceInformation("{0} could not be registered for disposal because the cancellation token could not be found", descriptionOfDisposable);

return;

}

Trace.TraceInformation("Registering for disposal: {0}", descriptionOfDisposable);

token.Register(() =>

{

Trace.TraceInformation("Disposing {0}", descriptionOfDisposable);

disposable.Dispose();

});

}

which is how you make something be properly disposed when an OWIN-based application shuts down. Moreover, I’m using Windsor’s installer mechanism to register stuff in the containers.

Rebus configuration

Next thing to do, is to make sure that I configure Rebus correctly – since I have two separate applications, I will also treat them as such when I set up Rebus. This means that my web tier will have a one-way client, because it needs only to be able to bus.Send, whereas the backend will have a more full configuration.

The one-way client might be configured like this:

public class WebRebusInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        var azureServiceBusConnectionString = ConfigurationManager
            .ConnectionStrings["azureServiceBusConnectionString"]
            .ConnectionString;

        Configure.With(new CastleWindsorContainerAdapter(container))
            .Transport(t => t.UseAzureStorageQueuesAsOneWayClient(azureServiceBusConnectionString))
            .Routing(r => r.TypeBased().MapAssemblyOf<SendEmail>("backend"))
            .Start();
    }
}

public class WebRebusInstaller : IWindsorInstaller

{

public void Install(IWindsorContainer container, IConfigurationStore store)

{

var azureServiceBusConnectionString = ConfigurationManager

.ConnectionStrings["azureServiceBusConnectionString"]

.ConnectionString;

Configure.With(new CastleWindsorContainerAdapter(container))

.Transport(t => t.UseAzureStorageQueuesAsOneWayClient(azureServiceBusConnectionString))

.Routing(r => r.TypeBased().MapAssemblyOf<SendEmail>("backend"))

.Start();

}

this registering an IBus instance in the container which is capable of sending SendEmail messages, which will be routed to the queue named backend.

And then, the backend might be configured like this:

public class BackendRebusInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        var azureServiceBusConnectionString = ConfigurationManager
            .ConnectionStrings["azureServiceBusConnectionString"]
            .ConnectionString;

        Configure.With(new CastleWindsorContainerAdapter(container))
            .Transport(t => t.UseAzureStorageQueues(azureServiceBusConnectionString, "backend"))
            .Start();
    }
}

public class BackendRebusInstaller : IWindsorInstaller

{

public void Install(IWindsorContainer container, IConfigurationStore store)

{

var azureServiceBusConnectionString = ConfigurationManager

.ConnectionStrings["azureServiceBusConnectionString"]

.ConnectionString;

Configure.With(new CastleWindsorContainerAdapter(container))

.Transport(t => t.UseAzureStorageQueues(azureServiceBusConnectionString, "backend"))

.Start();

}

Only thing left is to write the SendEmailHandler:

Email message handler

public class SendEmailHandler : IHandleMessages<SendEmail>
{
    public async Task Handle(SendEmail message)
    {
        var mail = CreateMailMessage(message);
        var client = GetSmtpClient();

        using(client)
        {
            await client.SendMailAsync(mail);
        }
    }

    MailMessage CreateMailMessage(SendEmail message)
    {
         //...
    }

    SmtpClient GetSmtpClient()
    {
         //...
    }
}

public class SendEmailHandler : IHandleMessages<SendEmail>

{

public async Task Handle(SendEmail message)

{

var mail = CreateMailMessage(message);

var client = GetSmtpClient();

using(client)

{

await client.SendMailAsync(mail);

}

MailMessage CreateMailMessage(SendEmail message)

{

//...

}

SmtpClient GetSmtpClient()

{

//...

}

Conclusion

Hosting a Rebus endpoint inside an Azure Web Site can be compelling for several reasons, where smooth deployment of cohesive units of web+backend can be made trivial.

I’ve done this several times myself, in web sites with multiple processes, including sagas and timeouts stored in SQL Azure, and basically everything Rebus can do – and so far, it has worked flawlessly.

Depending on your requirements, you might need to flick on the “Always On” setting in the portal

Skærmbillede 2015-08-21 kl. 11.44.22

so that the site keeps running even though it’s not serving web requests.

Final words

If anyone has experiences doing something similar to this in Azure or with another cloud service provider, I’d be happy to hear about it 🙂

(*) This 1-to-1-ness is, in my opinion, a thing that the microservices community does nok mention enough. I like to think about processes and applications much the same way as Udi Dahan describes it.

Topshelf and IoC containers

2014-02-27 by mookid8000 Leave a comment

To top off my previous post with an example on how almost any kind of application can be hosted as a Windows Service, I’ll show an example on how Topshelf can be used to host an IoC container.

As most developers probably know, an IoC container functions as a logical application container of sorts, helping with creating stuff when stuff needs to be created, and disposing stuff when stuff needs to be disposed, keeping whatever needs to be kept alive alive for the entire duration of the application lifetime.

This way, when we have this Topshelf-IoC-container framework in place, we can use it to activate all kinds of applications.

I’ll show how it’s done with Castle Windsor, but I think it should be fairly easy to port this solution to any other IoC container.

Create a service class that holds the container

First, let’s create a class that implements the Start/ Stop methods of ServiceControl – this class will initialize its Windsor container when it starts, and dispose it when it stops.

I’ve added some logging for good measure – when you’re a backend kind of guy, you come to appreciate a systematic and consistent approach towards logging in your Windows services, and I’m no exception.

class RobotService : ServiceControl
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    readonly WindsorContainer _container = new WindsorContainer();

    public bool Start(HostControl hostControl)
    {
        try
        {
            Log.Info("Initializing container");

            _container.Install(FromAssembly.This());

            return true;
        }
        catch (Exception exception)
        {
            Log.Error("An error occurred during intialization: {0}", exception);

            return false;
        }
    }

    public bool Stop(HostControl hostControl)
    {
        try
        {
            Log.Info("Disposing container");

            _container.Dispose();

            return true;
        }
        catch (Exception exception)
        {
            Log.Error("An error occurred during container disposal: {0}", exception);

            return false;
        }
    }
}

class RobotService : ServiceControl

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

readonly WindsorContainer _container = new WindsorContainer();

public bool Start(HostControl hostControl)

{

try

{

Log.Info("Initializing container");

_container.Install(FromAssembly.This());

return true;

}

catch (Exception exception)

{

Log.Error("An error occurred during intialization: {0}", exception);

return false;

}

public bool Stop(HostControl hostControl)

{

try

{

Log.Info("Disposing container");

_container.Dispose();

return true;

}

catch (Exception exception)

{

Log.Error("An error occurred during container disposal: {0}", exception);

return false;

}

Use Topshelf to activate the service class

Now we can have our RobotService activated as a Windows Service by adding the following C# spells:

class Program
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException += (o, ea) => Log.Fatal("Unhandled exception: {0}", ea.ExceptionObject);

        HostFactory.Run(f =>
        {
            f.UseNLog();
            f.Service<RobotService>();
        });
    }
}

class Program

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

static void Main()

{

AppDomain.CurrentDomain.UnhandledException += (o, ea) => Log.Fatal("Unhandled exception: {0}", ea.ExceptionObject);

HostFactory.Run(f =>

{

f.UseNLog();

f.Service<RobotService>();

});

}

Please note that Topshelf needs a little extra help with logging unhandled app domain exceptions, so I’ve added a little bit of Log.Fatal at the top.

Add components to the container to actually do something

Now, just to show some real action, I’ve added a single Windsor installer that looks like this:

public class TestInstaller : IWindsorInstaller
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<IDisposable>()
                .Instance(CreateAndStartTestTimer(interval: TimeSpan.FromSeconds(1)))
                .Named("TestTimer")
            );
    }

    Timer CreateAndStartTestTimer(TimeSpan interval)
    {
        var timer = new Timer(interval.TotalMilliseconds);
        timer.Elapsed += (o, ea) => Log.Info("woooH0000! It's going great!!1");
        timer.Start();
        return timer;
    }
}

public class TestInstaller : IWindsorInstaller

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

public void Install(IWindsorContainer container, IConfigurationStore store)

{

container.Register(

Component.For<IDisposable>()

.Instance(CreateAndStartTestTimer(interval: TimeSpan.FromSeconds(1)))

.Named("TestTimer")

);

}

Timer CreateAndStartTestTimer(TimeSpan interval)

{

var timer = new Timer(interval.TotalMilliseconds);

timer.Elapsed += (o, ea) => Log.Info("woooH0000! It's going great!!1");

timer.Start();

return timer;

}

As you can see, it will start a System.Timers.Timer, configured to periodically log a cheerful statement to the log and shove it in the container to be disposed when the application shuts down. It shouldn’t take too much imagination to come up with more useful and realistic tasks for the timer to perform.

This is actually all there is to it! Of course it can be customized if you want, but what I’ve shown is the only stuff that is necessary to create a full-blown Windows Service that manages the lifetime of application components and logs its work in a way that makes the service monitorable, e.g. by Microsoft SCOM and/or Splunk or whichever way you like to throw your logs.

As a public service, I’ve put this small example project in a GitHub repository for your cloning pleasure. Also, if you have any comments, please don’t hesitate to send them my way. Pull requests are also accepted 🙂

Domain events salvation example

2012-12-13 by mookid8000 3 Comments

One of the immensely awesome things that Udi Dahan has – if not invented, then at least brought to my attention – is the awesome “domain events – salvation” pattern.

If you’re familiar with the onion architecture, you’ve probably more than once experienced the feeling that you had the need to pull something from your IoC container some place deep in your domain model. In my experience, that often happens when you have a requirement on the form “when something happens bla bla, then some other thing must happen bla bla” where “something” and “some other thing” aren’t otherwise related.

An example could be when a new account (a.k.a. a customer that we mean to do business with) is registered in the system, we should make sure that our credit assessment of the account is fresh enough that we dare do the businesss.

I’ve found that the “domain events – salvation” provides a solution to that problem. Check this out:

public class Account
{
    public void Register()
    {
        // ... do stuff that marks this account as registered

        DomainEvents.Raise(new AccountRegistered(this));
    }
}

public class Account

{

public void Register()

{

// ... do stuff that marks this account as registered

DomainEvents.Raise(new AccountRegistered(this));

}

“Whoa, what was that?” you might ask… that was a domain object that did some stuff, and in the end it raised a “domain event”, telling to the world what just happened. And yes, that was a domain object calling out to some static nastiness – but I promise you, it isn’t as nasty as you may think.

I’d like to assure you that the Account class is fully unit testable – i.e. it can be tested in isolation, just like we want. And that’s because we can abstract the actual handling of the domain events out behind an interface, IHandleDomainEvents, which is what actually gets to take care of the domain events – something like this:

public class DomainEvents
{
    public static IHandleDomainEvents Current = new DevNullDomainEventsHandler();

    public static void Raise<T>(T domainEvent)
    {
        Current.Handle(domainEvent);
    }
}

public class DomainEvents

{

public static IHandleDomainEvents Current = new DevNullDomainEventsHandler();

public static void Raise<T>(T domainEvent)

{

Current.Handle(domainEvent);

}

and then IHandleDomainEvents can be implemented in several flavors and “injected” into the domain as a static dependency, e.g. this bad boy for testing:

public class TestDomainEventsHandlers : IHandleDomainEvents
{
    readonly List<object> raisedDomainEvents = new List<object>();

    public IEnumerable<object> RaisedDomainEvents { get { return raisedDomainEvents; } }

    public void Handle<T>(T domainEvent)
    {
        raisedDomainEvents.Add(domainEvent);
    }
}

public class TestDomainEventsHandlers : IHandleDomainEvents

{

readonly List<object> raisedDomainEvents = new List<object>();

public IEnumerable<object> RaisedDomainEvents { get { return raisedDomainEvents; } }

public void Handle<T>(T domainEvent)

{

raisedDomainEvents.Add(domainEvent);

}

which can be used by installing a new instance of it in the setup phase of each test, and then running assertions against the collected domain events in the assert phase.

The coolest part though, is the production implementation of IHandleDomainEvents – it may look like this:

public class CastleWindsorDomainEventDispatcher : IHandleDomainEvents
{
    readonly IWindsorContainer container;

    public CastleWindsorDomainEventDispatcher(IWindsorContainer container)
    {
        this.container = container;
    }

    public void Handle<T>(T domainEvent)
    {
        var subscribers = container.ResolveAll<ISubscribeTo<T>>().ToList();

        try
        {
            subscribers.ForEach(s => s.Handle(domainEvent));
        }
        finally
        {
            subscribers.ForEach(s => container.Release(s));
        }
    }
}

public class CastleWindsorDomainEventDispatcher : IHandleDomainEvents

{

readonly IWindsorContainer container;

public CastleWindsorDomainEventDispatcher(IWindsorContainer container)

{

this.container = container;

}

public void Handle<T>(T domainEvent)

{

var subscribers = container.ResolveAll<ISubscribeTo<T>>().ToList();

try

{

subscribers.ForEach(s => s.Handle(domainEvent));

}

finally

{

subscribers.ForEach(s => container.Release(s));

}

thus delegating the handling of domain events to all implementors of ISubscribeTo<TDomainEvent>. This way, if I have registered this guy in my container:

public class EnsureCreditAssessmentIsFresh : ISubscribeTo<AccountRegistered>
{
    public EnsureCreditAssessmentIsFresh(ILookMaADependency lookMaADependency)
    {
        this.lookMaADependency = lookMaADependency;
    }

    public void Handle(AccountRegistered accountRegistered)
    {
        // possibly initiate new credit assessment in here...
    }
}

public class EnsureCreditAssessmentIsFresh : ISubscribeTo<AccountRegistered>

{

public EnsureCreditAssessmentIsFresh(ILookMaADependency lookMaADependency)

{

this.lookMaADependency = lookMaADependency;

}

public void Handle(AccountRegistered accountRegistered)

{

// possibly initiate new credit assessment in here...

}

I can kick off a new credit assessment workflow when a new account is registered, and everything is wired together in a way that is semantically true to the domain. Also, my domain object suddenly get to pull stuff from the container (albeit in an indirect fashion), without even knowing about it!

Just a personal observation regarding the recent IoC debate on Twitter

2012-02-03 by mookid8000 1 Comment

Systems, where I’ve started out “as simple as possible”, and later wished that I had baked in an IoC container from the beginning: Several.

Systems, where I’ve baked in Castle Windsor from the beginning, and where I later wished that I hadn’t: 0.

#justsaying

(IMO, using an IoC container does not increase overall complexity – it just moves some of the complexity out of my code, and into a thing that implements a bunch of useful patterns in a slightly more opaque way than if I’d implemented those things myself.)

Using Windsor as an auto-mocking container

2011-10-05 by mookid8000 Leave a comment

One of my former colleagues blogged about using AutoFixture as an auto-mocking container the other day, which got me thinking about auto-mocking with Windsor.

Although I’ve never used auto-mocking myself, a few months ago, I answered a question on StackOverflow, hinting at how auto-mocking could be accomplished with Castle Windsor. I didn’t provide any example code though, so this post will show a more complete solution on how auto-mocking can be implemented with Windsor and Rhino Mocks[1. I realize that all the cool kids are using other mocking libraries these days. I’m still using Rhino though, but it should be a fairly trivial task to “port” this solution to another mocking library.].

A lazy component loader to generate the mocks

First, I create a simple ILazyComponentLoader that lazily registers a Rhino Mocks instance when a particular service is requested – like so:

public class AutoMockingLazyComponentLoader : ILazyComponentLoader
{
    public IRegistration Load(string key, Type service, IDictionary arguments)
    {
        return Component.For(service).Instance(MockRepository.GenerateMock(service, new Type[0]));
    }
}

public class AutoMockingLazyComponentLoader : ILazyComponentLoader

{

public IRegistration Load(string key, Type service, IDictionary arguments)

{

return Component.For(service).Instance(MockRepository.GenerateMock(service, new Type[0]));

}

– real simple. Windsor’s default lifestyle is singleton, which ensures that subsequent calls for the same service will give me the same mock instance.

Test fixture base class

Then I create a test fixture base class, which is supposed to act as exactly that: a fixture for the SUT:

public abstract class AutoMockingFixtureFor<TAppService>
{
    IWindsorContainer container;

    protected TAppService service;

    [SetUp]
    public void SetUp()
    {
        container = new WindsorContainer()
            .Register(Component.For<ILazyComponentLoader>().ImplementedBy<AutoMockingLazyComponentLoader>(),
                      Component.For<TAppService>());

        // build sut and inject mocks for all dependencies
        service = container.Resolve<TAppService>();

        DoSetUp();
    }

    protected virtual void DoSetUp() { }

    [TearDown]
    public void TearDown()
    {
        DoTearDown();

        container.Dispose()
    }

    protected virtual void DoTearDown() { }

    protected TDependency Dep<TDependency>()
    {
        return container.Resolve<TDependency>();
    }

    protected TMock Mock<TMock>() where TMock : class
    {
        return MockRepository.GenerateMock<TMock>();
    }
}

public abstract class AutoMockingFixtureFor<TAppService>

{

IWindsorContainer container;

protected TAppService service;

[SetUp]

public void SetUp()

{

container = new WindsorContainer()

.Register(Component.For<ILazyComponentLoader>().ImplementedBy<AutoMockingLazyComponentLoader>(),

Component.For<TAppService>());

// build sut and inject mocks for all dependencies

service = container.Resolve<TAppService>();

DoSetUp();

}

protected virtual void DoSetUp() { }

[TearDown]

public void TearDown()

{

DoTearDown();

container.Dispose()

}

protected virtual void DoTearDown() { }

protected TDependency Dep<TDependency>()

{

return container.Resolve<TDependency>();

}

protected TMock Mock<TMock>() where TMock : class

{

return MockRepository.GenerateMock<TMock>();

}

As you can see, my SetUp method creates a new WindsorContainer, registering nothing but my AutoMockingLazyComponentLoader and TAppService – the SUT type. It then uses the container to instantiate the SUT, storing it away in a protected instance variable for test cases to work on.

I included DoSetUp and DoTearDown methods for my test fixtures to override in case they need to – but in most cases, they should not be used because of the coupling they introduce between test cases.

Lastly, I have two methods: Dep, which allows me to access an injected service type (short for “dependency”), and Mock which allows me to generate a new mock object in case I need to mock something other than my SUT’s dependencies.

How to write a new test fixture

As a result of this, a test fixture for something called HandleUpdateDisturbanceForecast is reduced to something like this:

[TestFixture]
public class TestOfHandleUpdateDisturbanceForecast : AutoMockingFixtureFor<HandleUpdateDisturbanceForecast>
{
    [Test]
    public void UpdatesDriverWithReceivedObservableForecast()
    {
        // Arrange
        var now = 19.March(1979).At(12.Hours());
        var localUnit = new GenericDriver();
        Dep<IProvidesSiteToStartUp>().Stub(p => p.GetLocalUnitByAlias("ali")).Return(localUnit);

        // Act
        service.Handle(new UpdateDisturbanceForecast
                            {
                                LocalUnitAlias = "ali",
                                DisturbanceForecast = new List<DisturbancePlanEntry>
                                                            {
                                                                new DisturbancePlanEntry {Time = now, Disturbance = 2},
                                                            }
                            });

        // Assert
        var forecast = localUnit.DisturbanceForecast;
        Assert.AreEqual(1, forecast.Count);
        Assert.AreEqual(now, forecast[0].Time);
        Assert.AreEqual(2, forecast[0].Value);
    }
}

[TestFixture]

public class TestOfHandleUpdateDisturbanceForecast : AutoMockingFixtureFor<HandleUpdateDisturbanceForecast>

{

[Test]

public void UpdatesDriverWithReceivedObservableForecast()

{

// Arrange

var now = 19.March(1979).At(12.Hours());

var localUnit = new GenericDriver();

Dep<IProvidesSiteToStartUp>().Stub(p => p.GetLocalUnitByAlias("ali")).Return(localUnit);

// Act

service.Handle(new UpdateDisturbanceForecast

{

LocalUnitAlias = "ali",

DisturbanceForecast = new List<DisturbancePlanEntry>

{

new DisturbancePlanEntry {Time = now, Disturbance = 2},

}

});

// Assert

var forecast = localUnit.DisturbanceForecast;

Assert.AreEqual(1, forecast.Count);

Assert.AreEqual(now, forecast[0].Time);

Assert.AreEqual(2, forecast[0].Value);

}

– which I think looks pretty slick. And yes, this is an actual test case from something we’re building – doesn’t matter what it’s doing, just wanted to show an actual example.

It’s not like I’m saving a huge amount of coding here – I usually only instantiate my SUT in the SetUp method of my test fixtures, but I like how the “fixed style” of AutoMockingFixtureFor encourages application services to follow a pattern that makes for easy IoC and testing. And the fixture is relieved of almost all clutter that does not directly relate to the thing being tested.

Castle Windsor resolution logic: Cool handler filter that orders components

2011-08-15 by mookid8000 Leave a comment

As you can see from my previous post on handler filters, an IHandlersFilter will have a chance to do stuff to the array of handlers that would otherwise be used untouched during a call to ResolveAll ( ResolveAll is also what happens behind the scenes when a component relies on CollectionResolver to supply a collection of components for it to use).

Now, what is left is to implement some kind of logic that does something to the handlers array. First thing that comes to my mind is ordering the handlers!

Ordering the handlers is very relevant e.g. in scenarios where tasks are modeled as a series of steps that should be executed in a consistent fashion. An example could be a component ( TaskProcessor) that gets a collection of implementations of some task-like interface injected ( IEnumerable<ITask>).

Now, to ensure that this list of tasks is properly ordered, I’d like to specify a few hints on how they should be ordered. Not too little, because otherwise stuff would not work, but I also don’t want to be overly explicit on how the tasks should be ordered.

So I came up with a solution based on two attributes: ExecutesBeforeAttribute and ExecutesAfterAttribute, allowing types to position themselves in relation to other types they know about, and all other types to stay oblivious of what is going on.

One possible usage scenario could look like this, assuming we have modeled some kind of money transfer as a series of steps, each implementing ITask:

public interface ITask
{
    void Execute();
}

public class ExecutePayment : ITask { ... }

public class ValidateCreditCards : ITask { ... }

public class ValidateDebitAccountBalance : ITask { ... }

public class ReportWarnings : ITask { ... }

public class GenerateReceipt : ITask { ... }

public interface ITask

{

void Execute();

}

public class ExecutePayment : ITask { ... }

public class ValidateCreditCards : ITask { ... }

public class ValidateDebitAccountBalance : ITask { ... }

public class ReportWarnings : ITask { ... }

public class GenerateReceipt : ITask { ... }

and then a simplistic executor:

public class TaskExecutor
{
    readonly IEnumerable<ITask> tasks;

    public TaskExecutor(IEnumerable<ITask> tasks)
    {
        this.tasks = tasks;
    }

    public void ExecuteTasks()
    {
        foreach(var task in tasks)
        {
            task.Execute();
        }
    }
}

public class TaskExecutor

{

readonly IEnumerable<ITask> tasks;

public TaskExecutor(IEnumerable<ITask> tasks)

{

this.tasks = tasks;

}

public void ExecuteTasks()

{

foreach(var task in tasks)

{

task.Execute();

}

Now, carrying out a money transfer would consist of having the executor run through this list of discrete tasks, but it’s probably important that the validation occurs before the actual payment, and it probably doesn’t make sense to generate reports before the payment. Therefore, let’s decorate some of the steps:

public class ExecutePayment : ITask { ... }

[ExecutesBefore(typeof(ExecutePayment))]
public class ValidateCreditCards : ITask { ... }

[ExecutesBefore(typeof(ExecutePayment))]
public class ValidateDebitAccountBalance : ITask { ... }

[ExecutesAfter(typeof(ExecutePayment))]
public class ReportWarnings : ITask { ... }

[ExecutesAfter(typeof(ExecutePayment))]
public class GenerateReceipt : ITask { ... }

public class ExecutePayment : ITask { ... }

[ExecutesBefore(typeof(ExecutePayment))]

public class ValidateCreditCards : ITask { ... }

[ExecutesBefore(typeof(ExecutePayment))]

public class ValidateDebitAccountBalance : ITask { ... }

[ExecutesAfter(typeof(ExecutePayment))]

public class ReportWarnings : ITask { ... }

[ExecutesAfter(typeof(ExecutePayment))]

public class GenerateReceipt : ITask { ... }

and then make sure we respect them:

var container = new WindsorContainer();

// allow collections to be resolved
container.Kernel.Resolver.AddSubResolver(new CollectionResolver(container.Kernel));

// this is the new thing!
container.Kernel.AddHandlersFilter(new RespectOrderDirectivesHandlersFilter(typeof(ITask)));

container.Register(AllTypes.FromThisAssembly().BasedOn<ITask>().WithService.Base(),
                    Component.For<TaskExecutor>());

var container = new WindsorContainer();

// allow collections to be resolved

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

// this is the new thing!

container.Kernel.AddHandlersFilter(new RespectOrderDirectivesHandlersFilter(typeof(ITask)));

container.Register(AllTypes.FromThisAssembly().BasedOn<ITask>().WithService.Base(),

Component.For<TaskExecutor>());

Now, when the container builds a TaskExecutor, it will inject the ITask implementations in the order specified by the attributes. Inside RespectOrderDirectivesHandlersFilter, there’s a HandlerSorter, which is the implementation of the actual sorting algorithm. It builds a directed graph out of components and their dependents, and then it orders the components so that they will be traversed in a way that respects the order specified by the attributes. I’m not an expert on graph algorithms, so I don’t know if my implementation is really really stupid and slow – but I know that a) it works, and b) the ordering is cached, so the algorithm will only run once per set of handlers.

If you want to know more, or perhaps put RespectOrderDirectivesHandlersFilter to use, you can visit the RespectOrderDirectivesHandlersFilter page on GitHub.

Castle Windsor resolution logic: Handler filters

2011-08-10 by mookid8000 Leave a comment

One of the features I’m looking forward to in the upcoming Castle Windsor 3.0 (“Wawel”) release is handler filters! I’m especially looking forward to this feature because it solves a problem I have had quite a few times now, and also because it’s a feature that I’ve contributed to the Windsor project.

Please note that handler filter are NOT available before Windsor 3.0, which will probably be out sometime around middle August 2011.

As you can see, handler selectors is a hook in Resolve that sorts out the situation by choosing one handler among all the available handlers. Pretty much related to this, are handler filters, which is a hook in ResolveAll, that sorts out the situation by choosing and ordering several handlers from all the available handlers. Let’s take a look at a tiny example….

Example: Task processing pipeline

A golden use case for this feature is when you rely on CollectionResolver to inject a collection for you, e.g. in chain of responsibility-like scenarios like so:

public class TaskProcessor
{
    readonly IEnumerable<ITask> tasks;
    readonly IErrorReporter errorReporter;

    public TaskProcessor(IEnumerable<ITask> tasks, IErrorReporter errorReporter)
    {
        this.tasks = tasks;
        this.errorReporter = errorReporter;
    }

    public void ProcessTasks()
    {
        foreach(var task in tasks)
        {
            try
            {
                task.DoIt();
            }
            catch(SomeDomainException ex)
            {
                errorReporter.ReportErrorProcessingTask(task, ex);
                break;
            }
        }
    }
}

public class TaskProcessor

{

readonly IEnumerable<ITask> tasks;

readonly IErrorReporter errorReporter;

public TaskProcessor(IEnumerable<ITask> tasks, IErrorReporter errorReporter)

{

this.tasks = tasks;

this.errorReporter = errorReporter;

}

public void ProcessTasks()

{

foreach(var task in tasks)

{

try

{

task.DoIt();

}

catch(SomeDomainException ex)

{

errorReporter.ReportErrorProcessingTask(task, ex);

break;

}

Usually, when doing this kind of task processing, you care about the order in which the tasks are processed. Let’s pretend we have some tasks:

public class FinishTheJob : ITask
{
    public void DoIt()
    {
        Console.WriteLine("Finishing stuff");
    }
}

public class PrepareSomething : ITask
{
    public void DoIt()
    {
        Console.WriteLine("Preparing stuff");
    }
}

public class CarryItOut : ITask
{
    public void DoIt()
    {
        Console.WriteLine("Carrying out some important logic");
    }
}

public class FinishTheJob : ITask

{

public void DoIt()

{

Console.WriteLine("Finishing stuff");

}

public class PrepareSomething : ITask

{

public void DoIt()

{

Console.WriteLine("Preparing stuff");

}

public class CarryItOut : ITask

{

public void DoIt()

{

Console.WriteLine("Carrying out some important logic");

}

and the tasks are registered “dynamically” (allowing us to add new tasks just by dropping new implementations of ITask into the project), like so:

container.Register(AllTypes.FromThisAssembly().BasedOn<ITask>().WithService.Base());

1	container.Register(AllTypes.FromThisAssembly().BasedOn<ITask>().WithService.Base());

Now, how do we make sure that the PrepareSomething and FinishTheJob tasks are run at the right time, i.e. before and after CarryItOut? Handler filters to the rescue!

Let’s register a handler filter like so:

container.Kernel.AddHandlersFilter(new TaskHandlersFilter());

1	container.Kernel.AddHandlersFilter(new TaskHandlersFilter());

and the filter is implemented like this:

class TaskHandlersFilter : IHandlersFilter
{
    readonly Dictionary<Type, int> sortOrder = new Dictionary<Type, int>
                                                   {
                                                       {typeof (PrepareSomething), 1},
                                                       {typeof (CarryItOut), 2},
                                                       {typeof (FinishTheJob), 3},
                                                   };

    public bool HasOpinionAbout(Type service)
    {
        return service == typeof(ITask);
    }

    public IHandler[] SelectHandlers(Type service, IHandler[] handlers)
    {
        // come up with some way of ordering implementations here
        // (cool solution coming up in the next post... ;))
        return handlers
            .OrderBy(h => sortOrder[h.ComponentModel.Implementation])
            .ToArray();
    }
}

class TaskHandlersFilter : IHandlersFilter

{

readonly Dictionary<Type, int> sortOrder = new Dictionary<Type, int>

{

{typeof (PrepareSomething), 1},

{typeof (CarryItOut), 2},

{typeof (FinishTheJob), 3},

};

public bool HasOpinionAbout(Type service)

{

return service == typeof(ITask);

}

public IHandler[] SelectHandlers(Type service, IHandler[] handlers)

{

// come up with some way of ordering implementations here

// (cool solution coming up in the next post... ;))

return handlers

.OrderBy(h => sortOrder[h.ComponentModel.Implementation])

.ToArray();

}

Now, when my program does this:

foreach(var task in container.ResolveAll<ITask>())
{
    task.DoIt();
}

foreach(var task in container.ResolveAll<ITask>())

{

task.DoIt();

}

I get this output:

Preparing stuff
Carrying out some important logic
Finishing stuff

Preparing stuff

Carrying out some important logic

Finishing stuff

just as expected, which in turn means that CollectionResolver’s call to ResolveAll will also yield an ordered list of tasks.

One could also imagine that only certain handlers were returned, thus allowing tenants in multi-tenant scenarios to have different task processing pipelines.

Nifty, huh? In the next post, I will show a simple yet sophisticated way of ordering the handlers in the SelectHandlers method of a handler filter.

Castle Windsor resolution logic: Handler selectors

2011-08-08 by mookid8000 Leave a comment

Do you know what handler selectors are? It’s a way for you to register some logic in Windsor that will choose among all the available handlers when some particular component is resolved.

E.g. if you have a multi-tenant application with multiple implementations of IUserNotifier, let’s call them NotifyUserBySms and NotifyUserByEmail, and you need to make sure that one particular tenant whose employees are equipped with smartphones get notified by email, you can let a handler selector make this selection transparent to the rest of your application by adding a handler selector, like so:

class UserNotificationHandlerSelector : IHandlerSelector
{
    public bool HasOpinionAbout(string key, Type service)
    {
        return service == typeof (IUserNotifier);
    }

    public IHandler SelectHandler(string key, Type service, IHandler[] handlers)
    {
        // somehow determine whether employees of current tenant can receive emails
        Console.WriteLine("Does the current tenant' s employees have smartphones? (y/n)");

        switch (char.ToLower(Console.ReadKey().KeyChar))
        {
            case 'y':
                return handlers.Single(h => h.ComponentModel.Implementation == typeof (NotifyUserByEmail));
            default:
                return handlers.First(h => h.ComponentModel.Implementation != typeof (NotifyUserByEmail));
        }
    }
}

class UserNotificationHandlerSelector : IHandlerSelector

{

public bool HasOpinionAbout(string key, Type service)

{

return service == typeof (IUserNotifier);

}

public IHandler SelectHandler(string key, Type service, IHandler[] handlers)

{

// somehow determine whether employees of current tenant can receive emails

Console.WriteLine("Does the current tenant' s employees have smartphones? (y/n)");

switch (char.ToLower(Console.ReadKey().KeyChar))

{

case 'y':

return handlers.Single(h => h.ComponentModel.Implementation == typeof (NotifyUserByEmail));

default:

return handlers.First(h => h.ComponentModel.Implementation != typeof (NotifyUserByEmail));

}

thus making it possible for all other services to depend on IUserNotifier, not caring under which tenant’s context they’re running.

As you can see, this handler selector only has an opinion when an IUserNotifier is being resolved. And then, when its SelectHandler method is invoked, it gets to choose among all assignable handlers for that particular service type, effectively providing a way to make sure that some particular implementation is used, given some condition (here simulated by some Console.ReadKey() action).

Nifty huh? Only sad thing though, is that handler selectors are not pulled from the container – you have to supply an instance to the kernel, so if you need some services in the selector you need to pull them manually from the container. This can of course be overcome by supplying the handler selector with a reference to the container, allowing it to Resolve stuff at will – just remember – as always – to Release what you Resolve.

This was a short introduction to handler selectors – next post will be about something new, namely handler filters which is a new feature in Windsor 3.0.

How Windsor’s decorators can save your life (almost)

2011-01-18 by mookid8000 2 Comments

Have you ever needed some kind of “master switch” in your application – i.e. some central place to flick a bool, resulting is changed behavior in numerous places?

Recently, we got the requirement that our application could function in two modes: active and passive. In active mode, the application must work like usual, whereas in passive mode, the app must not do anything to the outside world.

In our app, doing stuff to the outside world can be two things:

Writing stuff to a bunch of external SCADA systems.
Publishing status messages via NServiceBus.

which means that in order to implement passive mode, we need to avoid doing these two things.

Now, since everything in our app is wired by Windsor, and Windsor supports the nifty decorator pattern, implementing this “master switch” was a breeze!

The master switch

First, we implemented something like this to capture the switch itself:

public class MasterSwitch
{
    public bool IsActive { get; set; }
}

public class MasterSwitch

{

public bool IsActive { get; set; }

}

which is registered like this:

container.Register(Component.For<MasterSwitch>().Lifestyle.Singleton);

1	container.Register(Component.For<MasterSwitch>().Lifestyle.Singleton);

Note th at the switch is a singleton, thus allowing all other services to have the same instance injected. Note also that concurrency is not an issue in our system – if MasterSwitch was to be used e.g. in an ASP.NET MVC application, it would have had a couple of locks in there or something similar.

Intercepting writes to external systems

All external hardware communication goes through an implementation of this interface:

public interface IExternalStuff
{
    void Write(string name, object value);
    object Read(string name);
}

public interface IExternalStuff

{

void Write(string name, object value);

object Read(string name);

}

so in order to abort all writes when we’re in passive mode, we added a new implementation of IExternalStuff that looks something like this:

public class ExternalStuffWithMasterSwitch : IExternalStuff
{
    readonly MasterSwitch masterSwitch;
    readonly IExternalStuff externalStuff;

    public ExternalStuffWithMasterSwitch(MasterSwitch masterSwitch, IExternalStuff externalStuff)
    {
        this.masterSwitch = masterSwitch;
        this.externalStuff = externalStuff;
    }

    public object Read(string name)
    {
        return externalStuff.Read(name);
    }

    public void Write(string name, object value)
    {
        if (!masterSwitch.IsMaster) return;

        externalStuff.Write(name, value);
    }
}

public class ExternalStuffWithMasterSwitch : IExternalStuff

{

readonly MasterSwitch masterSwitch;

readonly IExternalStuff externalStuff;

public ExternalStuffWithMasterSwitch(MasterSwitch masterSwitch, IExternalStuff externalStuff)

{

this.masterSwitch = masterSwitch;

this.externalStuff = externalStuff;

}

public object Read(string name)

{

return externalStuff.Read(name);

}

public void Write(string name, object value)

{

if (!masterSwitch.IsMaster) return;

externalStuff.Write(name, value);

}

Note how ExternalStuffWithMasterSwitch depends on IExternalStuff – this is where Windsor gets really cool, because if I remember to register my components in the following order:

container.Register(Component.For<IExternalStuff>()
                                      .ImplementedBy<ExternalStuffWithMasterSwitch>()
                                      .Lifestyle.Transient,
                   Component.For<IExternalStuff>()
                                      .Instance(new ExternalStuffViaSomeWrappedThirdPartyComponent()));

container.Register(Component.For<IExternalStuff>()

.ImplementedBy<ExternalStuffWithMasterSwitch>()

.Lifestyle.Transient,

Component.For<IExternalStuff>()

.Instance(new ExternalStuffViaSomeWrappedThirdPartyComponent()));

then Windsor is smart enough to resolve the ExternalStuffWithMasterSwitch supplying the next available implementation of IExternalStuff, instead of entering a cycle.

Thus, we have cancelled all writes through IExternalStuff in our entire application with a few lines of extra code.

Avoiding publishing status messages

First, we needed som way to tell if a message was a status message, which was pretty easy – now all our status messages “implement” this marker interface which in turn implements IMessage from NServiceBus:

public interface IStatusMessage : IMessage {}

1	public interface IStatusMessage : IMessage {}

So, in order to “swallow” all published status messages when we’re in passive mode, we implemented this decorator to IBus:

public class BusDecoratorThatSwallowsPublishedStatusMessages : IBus
{
    readonly MasterSwitch masterSwitch;
    readonly IBus bus;

    public BusDecoratorThatSwallowsPublishedStatusMessages(MasterSwitch masterSwitch, IBus bus)
    {
        this.masterSwitch = masterSwitch;
        this.bus = bus;
    }

    // (...) quite a few methods up here

    public void Publish<T>(T message) where T : IMessage
    {
        if (!masterSwitch.IsActive && message is IStatusMessage) return;

        bus.Publish(message);
    }
}

public class BusDecoratorThatSwallowsPublishedStatusMessages : IBus

{

readonly MasterSwitch masterSwitch;

readonly IBus bus;

public BusDecoratorThatSwallowsPublishedStatusMessages(MasterSwitch masterSwitch, IBus bus)

{

this.masterSwitch = masterSwitch;

this.bus = bus;

}

// (...) quite a few methods up here

public void Publish<T>(T message) where T : IMessage

{

if (!masterSwitch.IsActive && message is IStatusMessage) return;

bus.Publish(message);

}

which must be registered before NServiceBus’ own IBus gets registered:

container.Register(Component.For<IBus>()
                      .ImplementedBy<BusDecoratorThatSwallowsPublishedStatusMessages>()
                      .Lifestyle.Transient);

NServiceBus.Configure.With()
                   .CastleWindsorBuilder(container)
                   // (...)

container.Register(Component.For<IBus>()

.ImplementedBy<BusDecoratorThatSwallowsPublishedStatusMessages>()

.Lifestyle.Transient);

NServiceBus.Configure.With()

.CastleWindsorBuilder(container)

// (...)

I think this is a really cool example on how wiring everything with an IoC container provides some cool hooks in an application, allowing you to modify behavior in an extremely agile and non-intrusive manner.

How to avoid (unnecessarily) touching the container

2010-12-23 by mookid8000 2 Comments

…or “How to resolve stuff all over the place” – two appropriate titles for a blog post that shows the solution to a problem you will eventually run into when using an IoC container… if not in your first application, then maybe in the next…

What’s the problem?

Not all applications lend themselves equally well to leveraging an IoC container for resolving stuff. Generally, applications that follow some kind of request-response pattern are easy to adapt to use the container to build objects that handle requests: Just resolve some kind of handler that handles each request.

E.g.: It is trivial to make Castle Windsor resolve/release controllers in an ASP.NET MVC application by implementing a CastleWindsorControllerFactory.

There are applications however, that do not follow this kind of pattern – or at least not as clearly. Take for instance a typical Windows Forms desktop application that looks like this:

public static void Run()
{
    // yield control to winforms event loop...
    Application.Run(new MainForm());
}

public static void Run()

{

// yield control to winforms event loop...

Application.Run(new MainForm());

}

An attempt to use the container could look like this:

public static void Run()
{
    using(var container = new WindsorContainer().Install(FromAssembly.This()))
    {
        var mainForm = container.Resolve<MainForm>();

        // yield control to winforms event loop...
        Application.Run(mainForm);

        container.Release(mainForm);
    }
}

public static void Run()

{

using(var container = new WindsorContainer().Install(FromAssembly.This()))

{

var mainForm = container.Resolve<MainForm>();

// yield control to winforms event loop...

Application.Run(mainForm);

container.Release(mainForm);

}

But then one problem remains: How can we make the Windows Forms application use our beloved Windsor Container without resolving the entire world at this point?

E.g. if MainForm at some point needs to show a SubForm, then how do we do that without doing a new SubForm() inside of MainForm, thus tying MainForm directly to the concrete SubForm? (and worse: ruining our ability to unit test MainForm…?)

Let’s try using a service locator

In order to avoid new’ing up SubForm, we could use a service locator to provide the form to us. Consider this button handler:

void ButtonOpenSubFormClicked(object sender, EventArgs ea)
{
    var form = ServiceLocator.Resolve<SubForm>();

    form.Show();
}

void ButtonOpenSubFormClicked(object sender, EventArgs ea)

{

var form = ServiceLocator.Resolve<SubForm>();

form.Show();

}

That solves the problem, right? Wrong! I mean, now SubForm can have dependencies injected and stuff, but MainForm is tied to a class called ServiceLocator with a static generic method that creates stuff.

That’s pretty hard to unit test, and in the long run this will just prove to be a serious PITA.

How to fix the problem

If we wanted to fix the problem with MainForm and SubForm, we could do it by passing a ISubFormFactory to MainForm like so:

public interface ISubFormFactory
{
    SubForm CreateSubForm();
}

public class MainForm
{
    readonly ISubFormFactory subFormFactory;

    public MainForm(ISubFormFactory subFormFactory)
    {
        this.subFormFactory = subFormFactory;
    }
}

public interface ISubFormFactory

{

SubForm CreateSubForm();

}

public class MainForm

{

readonly ISubFormFactory subFormFactory;

public MainForm(ISubFormFactory subFormFactory)

{

this.subFormFactory = subFormFactory;

}

thus allowing MainForm to instantiate SubForms at will without depending directly on the container. Now on to implement ISubFormFactory:

public class UncoolSubFormFactory : ISubFormFactory
{
    public SubForm CreateSubForm()
    {
        // oh noes not again..!!1:
        return ServiceLocator.Resolve<SubForm>();
    }
}

public class UncoolSubFormFactory : ISubFormFactory

{

public SubForm CreateSubForm()

{

// oh noes not again..!!1:

return ServiceLocator.Resolve<SubForm>();

}

Now, why is that implementation uncool? There are several reasons, and two of them are: 1) I’m tying myself to a Windsor container somewhere in a static variable in my app, and 2) The implementation is stupid and boilerplate – I need to write one of these every time I need to show a new form… Uncool!

Enter TypedFactoryFacility

Windsor comes with a bunch of facilities in the box, and one of them fits this gap nicely: <a href="http://stw.castleproject.org/Windsor.Typed-Factory-Facility.ashx">TypedFactoryFacility</a>.

If TypedFactoryFacility had a tagline it would be either “The missing link!” or “Gimme another chance!” or something like that.

Put shortly, TypedFactoryFacility gives the container the ability to dynamically implement the ISubFormFactory interface from above, thus allowing my code to pull stuff from the container without even knowing it! \o/

In order to do that, I need to start out by registering the facility;

container.AddFacility<TypedFactoryFacility>();

1	container.AddFacility<TypedFactoryFacility>();

and then I need to register my factory service like so:

container.Register(Component.For<ISubFormFactory>().AsFactory());

1	container.Register(Component.For<ISubFormFactory>().AsFactory());

Now the container will delegate the call to CreateSubForm() to container.Resolve<SubForm>(), based on the return type of the factory method – nifty!

When working with Windsor, it is very important that everything that has a transient lifestyle gets properly released! – the facility has this capability as well, just implement a method with the following signature on the factory: void Release(SubForm subForm).

Now our MainForm’s event handler can look like this:

void ButtonOpenSubFormClicked(object sender, EventArgs ea)
{
    var form = subFormFactory.CreateSubForm();
    form.Closed += delegate { subFormFactory.Release(form); };
    form.Show();
}

void ButtonOpenSubFormClicked(object sender, EventArgs ea)

{

var form = subFormFactory.CreateSubForm();

form.Closed += delegate { subFormFactory.Release(form); };

form.Show();

}

allowing Windsor to properly take care of decommission concerns, thus properly disposing IDisposables and more.

I hope this post gave an understandable introduction to TypedFactoryFacility. To help some more, I have created a simple Windows Forms application on GitHub that shows how a simple Windows Forms application can implement a simple MVC pattern using Castle Windsor and TypedFactoryFacility.

Comments, questions and suggestions are appreciated 🙂