Category: Windsor

This post is a playground for me, to try out some ideas I want to include in my talk about Windsor at KGD.NET meeting later this month.

Scenario

We have a messaging application built around two interfaces:

public interface Command

{

}

public interface Handler

{

    void Execute();

}

public interface Handler<T> : Handler where T : Command

{

    T Command { get; set; }

}

Hopefully I don’t have to explain how they work. The idea is, application receives commands from somewhere, then it pulls all handlers registered for this command and let them handle the command. Split of Handler interface into generic and non-generic part is there to make up for lack of co/contra-variance in .NET 3.5.

Commands and Handlers

Handlers are quite simple classes implementing closed version of Handler<> interface. For example to change client’s address we’d have the following command

[Serializable]

public class UpdateClientCorrespondenceAddressCommand : Command

{

    private readonly AddressDto address;

    private readonly Guid clientId;

    public UpdateClientCorrespondenceAddressCommand(Guid clientId, AddressDto address)

    {

        this.clientId = clientId;

        this.address = address;

    }

    public AddressDto Address

    {

        get { return address; }

    }

    public Guid ClientId

    {

        get { return clientId; }

    }

}

and its handler:

public class UpdateClientCorrespondenceAddressHandler : Handler<UpdateClientCorrespondenceAddressCommand>

{

    private readonly Repository<Client> clientRepository;

    public UpdateClientCorrespondenceAddressHandler(Repository<Client> clientRepository)

    {

        this.clientRepository = clientRepository;

    }

    public UpdateClientCorrespondenceAddressCommand Command { get; set; }

    public void Execute()

    {

        var command = Command;

        if (command == null) return;

        var client = clientRepository.Get(command.ClientId);

        client.ChangeCorrespondenceAddress(command.Address);

        clientRepository.Update(client);

    }

}

Nothing earth shattering here. We would have similar set up for other business events in the application. We assume we can have more than one handler for single command (for example another handler would update shipping costs and promotions available for the new address of the client).

The ability to pull multiple services from the container via typed factory is not available in Windsor 2.1.1 – you need the trunk version to take advantage of it.

Registration

To register the code we create an installer:

public class Installer : IWindsorInstaller

{

    public void Install(IWindsorContainer container, IConfigurationStore store)

    {

        container.AddFacility<TypedFactoryFacility>()

            .Register(

                Component.For<ITypedFactoryComponentSelector>().ImplementedBy<HandlerSelector>(),

                Component.For<AutoReleaseHandlerInterceptor>(),

                AllTypes.FromAssemblyContaining<Program>()

                    .BasedOn(typeof(Repository<>))

                    .WithService.Base()

                    .Configure(c => c.LifeStyle.Singleton)

                    .BasedOn(typeof(Handler<>))

                    .WithService.Base()

                    .Configure(c => c.LifeStyle.Is(LifestyleType.Transient)

                                        .Interceptors<AutoReleaseHandlerInterceptor>()),

                Component.For<HandlerFactory>().AsFactory());

    }

}

There are a couple interesting things here. First we register typed factory facility, which we’ll use later on to pull handlers for commands we receive. Then we register custom selector for typed factory (discussed below), and an interceptor (discussed below). Then we  register all repositories and all handlers from given assembly, configuring handlers with transient lifestyle and with the interceptor we registered above. Lastly we also register typed factory for handlers:

public interface HandlerFactory

{

    Handler[] GetHandlersForCommand(Command command);

}

Typed factory selector

The handler factory has to do quite a lot of work for us. Given an instance of a command, it has to pull from the container all the handlers for the command’s type. To do this we need to use a custom selector (and trunk version of Windsor).

public class HandlerSelector:ITypedFactoryComponentSelector

{

    public TypedFactoryComponent SelectComponent(MethodInfo method, Type type, object[] arguments)

    {

        Debug.Assert(arguments.Length == 1);

        var message = arguments[0];

        var handlerType = typeof(Handler<>).MakeGenericType(message.GetType());

        return new TypedFactoryComponentCollection(handlerType.MakeArrayType(), new Arguments(arguments));

    }

}

Based on the command’s type we create closed Handler<> type and return TypedFactoryComponentCollection (new type that pulls all components for given service) passing down the command as typed argument to the resolution.

Putting it all together

We can now use the code like this:

private static void Main()

{

    using(var container = new WindsorContainer().Install(new Installer()))

    {

        var factory = container.Resolve<HandlerFactory>();

        DoActualWork(factory);

        Console.ReadKey(true);

    }

}

private static void DoActualWork(HandlerFactory factory)

{

    var command = ImmitateCommandArrived();

    var handlers = factory.GetHandlersForCommand(command);

    foreach (var handler in handlers)

    {

        handler.Execute();

    }

}

private static Command ImmitateCommandArrived()

{

    return new UpdateClientCorrespondenceAddressCommand(Guid.NewGuid(), GetSomeAddress());

}

Notice how simple the calling code is. It has no knowledge of the (quite complex) process that takes place behind the scenes to create strongly typed instances of appropriate classes. It does not even know what actual type of command it got.

What about releasing transient handlers?

Isn’t this code too simple though? It resolves handlers, which are transient components and it does not release them. And we all know transient components need to be released in Windsor, right?

Well – it does release them actually, it just doesn’t do it explicitly. Remember we registered an interceptor with all handlers. Here’s how that interceptor looks like:

[Transient]

public class AutoReleaseHandlerInterceptor : IInterceptor

{

    private static readonly MethodInfo Execute = typeof(Handler).GetMethod("Execute");

    private readonly IKernel kernel;

    public AutoReleaseHandlerInterceptor(IKernel kernel)

    {

        this.kernel = kernel;

    }

    public void Intercept(IInvocation invocation)

    {

        if(invocation.Method!=Execute)

        {

            invocation.Proceed();

            return;

        }

        try

        {

            invocation.Proceed();

        }

        finally

        {

            kernel.ReleaseComponent(invocation.Proxy);

        }

    }

}

The interceptor releases the component after the call to Execute for us. Thanks to this we take the burden (no pun intended) of releasing the components from the callers, and we make sure our handlers won’t leak memory. This is quite a useful trick actually, and while I have precisely zero knowledge of NServiceBus, I think it could be used to fix the issue Davy discussed, without having to mess with release policy.

With Windsor 2.1.1 out the door, we’re already working on version 3.0 (and looking for your feedback and ideas for the next version!). Yesterday I committed first “big” feature that probably will make it to the release.

DISCLAIMER:

All the code shown here represents a work in progress. Keep in mind that final version may be different. This also means that any feedback on this feature is appreciated.

Named Arguments

In current version of Windsor you can define inline dependencies for a component in at least three different ways:

• When registering it (with value obtained at registration time):

  container.Register(

      Component.For<ICustomer>()

          .ImplementedBy<CustomerImpl>()

          .DependsOn(

              Property.ForKey("Name").Eq("Caption Hook"),

              Property.ForKey("Address").Eq("Fairyland"),

              Property.ForKey("Age").Eq(45)

              )

          );

• When registering it (with value obtained at resolution time), AKA – Dynamic Parameters

  container.Register(

      Component.For<ClassWithArguments>()

          .LifeStyle.Transient

          .DynamicParameters((k, d) =>

          {

              d["timeStamp"] = DateTime.Now;

              d["user"] = Thread.CurrentPrincipal.Identity;

          })

      );

• When resolving it (although this is something you should strive to avoid, using constructor injection and/or Typed factory facility)

var component = container.Resolve<ClassWithArguments>(new

{

    TimeStamp = DateTime.Now,

    User = Thread.CurrentPrincipal.Identity

});

What all these approaches have in common is that you specify dependency by name. Windsor when resolving the component will then use the value you provided for constructor arguments or settable properties with that name it finds on the component. What if you don’t care about the name?

Typed Arguments

Trunk version of Windsor lets you do just that – omit the name in which case Windsor will use the type of the argument as the sole information when building your component.

container.Register(

       Component.For<ClassWithArguments>()

           .Lifestyle.Transient

           .DependsOn(

              Property.ForKey<DateTime>().Eq(DateTime.Now),

              Property.ForKey<IIdentity>().Eq(Thread.CurrentPrincipal.Identity))

    );

As you can see here we use the type as the key for the dependency. This works also with dynamic parameters as well as when passing arguments straight from the call site. A new class – Arguments has been introduced to accommodate this new feature (although ordinal Hashtable or Dictionary<object,object> will do just fine as well) .

container.Resolve<ClassWithArguments>(

    new Arguments(new object[]

    {

        DateTime.Now,

        Thread.CurrentPrincipal.Identity

    })

);

The Arguments class itself implements IDictionary and can wrap either another IDictionary containing either named or typed arguments, anonymous type containing named arguments or array of objects to be used as typed arguments. It is advised to use this type when you plan to use typed arguments.

Additionally to help you deal with filling the dictionaries in more usable fashion an extension method on IDictionary (so they work for Arguments type as well) called Insert (with few overloads) has been introduced. It lets you insert arguments in a fluent, more user friendly fashion.

container.Register(

    Component.For<ClassWithArguments>()

    .DynamicParameters((k, d) =>

        d.Insert(DateTime.Now)

        .Insert(Thread.CurrentPrincipal.Identity))

    );

Final words

While this may be appealing at first to use typed arguments everywhere, resist the temptation unless you have a good reason. Named arguments should always be your first choice. Name is a valuable contextual information that may improve the readability of your code. Windsor will favor named arguments over typed and use the latter only if it can’t find a matching named argument.

Jimmy published very interesting post about generic registration of certain partially closed types in StructureMap container. Go read the entire post first, it’s really worth it.

You’re back? OK. Jimmy uses StructureMap container in his sample, and after I saw it I immediately thought about doing the same thing in Windsor. That’s what this post is all about – how to make the following test pass:

Test

[Test]

public void Should_connect_delete_handler()

{

    var container = new WindsorContainer();

    container.AddFacility<HandlerFacility>();

    container.Register(AllTypes.FromAssemblyContaining<DeleteCustomerCommand>()

                        .BasedOn<IEntity>()

                        .BasedOn(typeof(IHandler<>)).WithService.Base()); // [a]

    var handler = container.Resolve<IHandler<DeleteEntityCommand<Customer>>>();

    Assert.IsInstanceOf<DeleteEntityCommandHandler<Customer>>(handler);

}

Solution

The line marked with [a] registers types implementing IHandler<>. It will register DeleteEntityCommandHandler<> with IHandler<>.  This is the equivalent of StructureMap’s ConnectImplementationToTypesClosing in Windsor.

As you can see I also registered a facility – HandlerFacility which does the actual magic, and is unsurprisingly quite similar to Jimmy’s DeleteCommandRegistrationConvention.

public class HandlerFacility : AbstractFacility

{

    private static readonly Type openDeleteCommandType = typeof(DeleteEntityCommand<>);

    private static readonly Type openHandlerInterfaceType = typeof(IHandler<>);

    private static readonly Type openDeleteCommandHandlerType = typeof(DeleteEntityCommandHandler<>);

    protected override void Init()

    {

        Kernel.HandlerRegistered += OnHandlerRegistered;

    }

    private void OnHandlerRegistered(IHandler handler, ref bool statechanged)

    {

        var type = handler.ComponentModel.Implementation;

        if (type.IsAbstract || typeof(IEntity).IsAssignableFrom(type) == false)

        {

            return;

        }

        var closedDeleteCommandType = openDeleteCommandType.MakeGenericType(type);

        var closedHandlerInterfaceType = openHandlerInterfaceType.MakeGenericType(closedDeleteCommandType);

        var closedDeleteCommandHandlerType = openDeleteCommandHandlerType.MakeGenericType(type);

        Kernel.Register(

            Component.For(closedHandlerInterfaceType)

                .ImplementedBy(closedDeleteCommandHandlerType)

                .LifeStyle.Transient);

    }

}

Just to set the record straight – you don’t really need a facility for that .You could hook an anonymous delegate to container kernel’s event and do that work inline. Having a facility is however my preferred solution since it encapsulates the work nicely, and gives you access to configuration, provided you’d ever want to externalize some part of the facility.

That’s all we needed to make the test pass: