Category: Castle

Neal started looking into behaviour of child containers in Windsor. This is an area that’s very rarely used, and as Hammett wrote two years ago – this is speaking with the devil himself. No one really ever uses it so it never got well defined and as Neal found out there are certain inconsistencies, and grey areas there.

This was a don’t ask, don’t tell area, and since Neil opened that can of worms, it’s time to deal with the issue. I’m considering several solutions, and the one I’m leaning towards most would be probably the most controversial.

Remove support for child containers altogether?

Basically handler selectors and sub-resolvers give you all the power you need to handle scenarios where you would want to use child container instead. I think removing the child containers, and add some nicer support for contextual scoping of components would be the best solution.

The point of this post however is to get your thoughts on this issue. Are you using child containers in Windsor? What are you using it for? How are you using it? Write a comment or if you don’t want to share that in public just drop me an email. I’d really like to get a clean picture of how usage of this feature looks like at this point in time, before I make a decision.

Disclaimer:

Notice that code shown here is quite new and is subject to change. If you’re reading this and it’s 2010 it’s likely that the code now is slightly different. I may come back and revisit the post if there are any changes, but don’t hold my word on it.

Pulling from the container

General rule of thumb when using IoC containers is – when you’re referencing your container in your components (anywhere outside of your bootstrapping code) you’re doing it wrong. As with all rules there are exceptions, but they are rare. Still, there are cases where you have to pull from the container somehow. What to do then? Let’s use the following artificial example:

public class MessageDispatcher

{

    public void Dispatch(IMessage message)

    {

        var handler = GetHandlerFor(message);

        handler.Handle(message);

        Destroy(handler);

    }

    private IMessageHandler GetHandlerFor(IMessage message)

    {

        // how to implement this...

    }

    private void Destroy(IMessageHandler handler)

    {

        // ... and this?

    }

}

Solution – take one – the ugly

The easiest option to implement is just to take dependency on the container.

private IKernel container;

private IMessageHandler GetHandlerFor(IMessage message)

{

    return container.Resolve<IMessageHandler>(new { name = message.Name });

}

private void Destroy(IMessageHandler handler)

{

    container.ReleaseComponent(handler);

}

This option seems the easiest at first. You just call the container directly. However along the way you coupled your component to the container which has whole list of disadvantages and is the wrong thing™ to do.

Solution – take two – the bad

Ok, so if calling the container directly is bad, we can use a layer of abstraction on top of it, right? Like Common Service Locator for example… This way we can swap the container underneath which proves the component has no dependency on the container.

Well, this is certainly a step in the right direction, but it still has a whole range of flaws. First of all – it won’t work in our scenario. Take a closer look at the code above – when we’re resolving the message handler, we’re also passing an argument in. CSL does not support passing parameters. Besides, using CSL just hides the problem instead of solving it – you’re still having a dependency on an infrastructure library in your domain component.

Solution – take three – the good

The least worst way of solving this problem is to introduce dedicated factory which will hide the container from your domain. Doing this manually (provided you want to do it right™) is however a lot of tedious boring work. You have to define an interface for your factory in your domain assembly, then create an implementation in another one, then actually implement all the calls (and not only to resolve, don’t forget about cleaning up after yourself), which as you’ll soon discover is a lot of repetitious code.

public class MessageDispatcher

{

    public void Dispatch(IMessage message)

    {

        var handler = GetHandlerFor(message);

        handler.Handle(message);

        Destroy(handler);

    }

    private void Destroy(IMessageHandler handler)

    {

        factory.DestroyHandler(handler);

    }

    private IMessageHandlerFactory factory;

    private IMessageHandler GetHandlerFor(IMessage message)

    {

        return factory.CreateNewHandler(message.Name);

    }

}

public interface IMessageHandlerFactory

{

    IMessageHandler CreateNewHandler(string name);

    void DestroyHandler(IMessageHandler handler);

}

// in another assembly

public class MessageHandlerFactory : IMessageHandlerFactory

{

    private IKernel container;

    public IMessageHandler CreateNewHandler(string name)

    {

        return container.Resolve<IMessageHandler>(new { name =name });

    }

    public void DestroyHandler(IMessageHandler handler)

    {

        container.ReleaseComponent(handler);

    }

}

Wouldn’t it be good if someone else could do the work for you? – Meet Typed Factory Facility.

Windsor Typed Factory Facility

Typed factory is just the tool for this problem – it’s an automatically created factory, created by container, but your code is unaware of the container. It’s been around since 2005 but due to severe limitations imposed on it, and lack of development in recent years it hasn’t been widely used.

However it’s been recently retuned, with new capabilities and old limitations have been removed. It’s considerably more usable now, hence the word reborn in the title on this post. Let’s get to the code, shall we?

var container = new WindsorContainer();

container.AddFacility<TypedFactoryFacility>();

container.Register(

    // register the handler and all the other components

    Component.For<MessageDispatcher>(), // register the component with dependency on our factory

    Component.For<IMessageHandlerFactory>().AsFactory() //register the factory itself (just the interface)!

    ); // that's it, now get the dispatcher

var dispatcher = container.Resolve<MessageDispatcher>();

//start dispatching...

we register the facility with the container, than we register all the components the usual way. When we want to use an interface as a factory, we register it without any implementation (if you pass an implementation it will be ignored) and then call the AsFactory() extension method, and we’re all set.

Now the kernel will implement the factory for you based on few conventions

• all the void methods are assumed to be used to release components passed as arguments
• all the non-void methods are assumed to be used to resolve components from the container
• If the factory implements IDisposable, the call to dispose will release all the transient components that were resolved via the factory.

Now, how does the factory know which service to request from the container? By default:

• Method’s return type is used to request the component by type
• If the method on the factory interface is called GetSOMETHING, the component called SOMETHING will be requested by name
• All the arguments passed to the method, will be forwarded to the container with names of the method’s parameters.

This however, is just the default behavior – you can easily change it, by implementing ITypedFactoryComponentSelector and registering it with the container. Then your implementation will be picked, and used to bind factory methods and their arguments to information used by the resolve appropriate components.

Custom ITypedFactoryComponentSelector – example

For example, let’s say you don’t like the GetSOMETHING convention, and decided that if the first argument of typed factory method is a string, it should be bound to component’s name instead.

public class MySelector: ITypedFactoryComponentSelector

{

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

    {

        string componentName = null;

        if(arguments.Length>0 && arguments[0] is string)

        {

            componentName = arguments[0].ToString();

        }

        //let's ignore all other arguments here for simplicity sake

        return new TypedFactoryComponent(componentName, method.ReturnType, null);

    }

}

Little bonus

One thing about this facility that blew my mind, is that the factory is not limited to resolving a single type –  with literally no effort you can use it to build a generic service locator.

public interface IGenericFactory

{

    T Create<T>();

}

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

var one = factory.Create<ISomeComponent>();

var two = factory.Create<IOtherComponent>();

The code is in the trunk. It may still contain bugs and not support all scenarios, so approach with caution, and as always – any feedback is appreciated.

Few months ago, a user asked the following question on the Castle users discussion group. A friend asked me about the same thing today, so I thought I’d blog this so that’s easier to find than the discussion group thread. Anyway, here’s the question:

say I have the following types

public interface ISometype<T> {} 

public class SomeTypeImpl<T>:ISometype<T> {} 

public class SomeSpecificTypeImpl<T>:ISometype<T> where T: ISomeSpecificSpecifier {} 

public interface ISomeSpecificSpecifier { } 

Is there a way to register ISomeType<> in the container so that for the general case it uses SomeTypeImpl<> but for cases where T is ISomeSpecificSpecifier it could use SomeSpecificTypeImpl<>?

Solution take one – the explicit version

The solution may be similar to the following sketchy code.

class Program

{

    static void Main(string[] args)

    {

        var container = new WindsorContainer();

        container.Register(Component.For(typeof(ISometype<>)).ImplementedBy(typeof(SomeTypeImpl<>)),

                           Component.For(typeof(ISometype<>)).ImplementedBy(typeof(SomeSpecificTypeImpl<>))

                               .PreferredFor<ISomeSpecificSpecifier>());

        var selector = new Selector();

        container.Kernel.AddHandlerSelector(selector);

        var sometype = container.Resolve<ISometype<string>>();

        Debug.Assert(sometype.GetType() == typeof(SomeTypeImpl<string>));

        var sometype2 = container.Resolve<ISometype<Specifier>>();

        Debug.Assert(sometype2.GetType() == typeof(SomeSpecificTypeImpl<Specifier>));

    }

}

public static class Preferred

{

    public static ComponentRegistration<object> PreferredFor<TClosingGenericType>(this ComponentRegistration<object> registration)

    {

        return registration.ExtendedProperties(new Preference(typeof(TClosingGenericType)));

    }

}

internal class Preference

{

    public static readonly string Name = "PreferredForClosingType";

    public Type PreferredForClosingType { get; set; }

    public Preference(Type type)

    {

        this.PreferredForClosingType = type;

    }

}

public class Selector : IHandlerSelector

{

    public bool HasOpinionAbout(string key, Type service)

    {

        // that's about as much as we can say at this point...

        return service.IsGenericType && service.GetGenericArguments().Length == 1;

    }

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

    {

        var @default = handlers.FirstOrDefault(h => MatchHandler(service, h));

        return @default ?? handlers.First();

    }

    private bool MatchHandler(Type service, IHandler handler)

    {

        if (handler.ComponentModel.ExtendedProperties.Contains(Preference.Name) == false)

            return false;

        var closingTypeRequired = (Type)handler.ComponentModel.ExtendedProperties[Preference.Name];

        var closingTypeActual = service.GetGenericArguments().Single();

        return closingTypeRequired.IsAssignableFrom(closingTypeActual);

    }

}

This version contains an explicit extension to the component registration API, to specify which component you prefer in which case. It also uses and IHandlerSelector implementation to do the actual work during resolution. It is possible however to not extend the API, and use the information we already have

Solution take two – the implicit version

class Program

{

    static void Main(string[] args)

    {

        var container = new WindsorContainer();

        container.Register(Component.For(typeof(ISometype<>)).ImplementedBy(typeof(SomeTypeImpl<>)),

                           Component.For(typeof(ISometype<>)).ImplementedBy(typeof(SomeSpecificTypeImpl<>)));

        var selector = new Selector();

        container.Kernel.AddHandlerSelector(selector);

        var sometype = container.Resolve<ISometype<string>>();

        Debug.Assert(sometype.GetType() == typeof(SomeTypeImpl<string>));

        var sometype2 = container.Resolve<ISometype<Specifier>>();

        Debug.Assert(sometype2.GetType() == typeof(SomeSpecificTypeImpl<Specifier>));

    }

}

public class Selector : IHandlerSelector

{

    public bool HasOpinionAbout(string key, Type service)

    {

        // that's about as much as we can say at this point...

        return service.IsGenericType && service.GetGenericArguments().Length == 1;

    }

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

    {

        return handlers.FirstOrDefault(h => MatchHandler(service, h));

    }

    private bool MatchHandler(Type service, IHandler handler)

    {

        var closingTypeRequired = handler.ComponentModel.Implementation.GetGenericArguments()

            .Single().GetGenericParameterConstraints().SingleOrDefault();

        if (closingTypeRequired == null)

            return false;

        var closingTypeActual = service.GetGenericArguments().Single();

        return closingTypeRequired.IsAssignableFrom(closingTypeActual);

    }

}

This version relies on the information provided in component’s generic type constraints. The Registration API is not extended, and we just do a little bit more work in the selector. Is this version better? It depends. The explicit version is… well – explicit about what it does, and for which components. The implicit one works on its own and if you’re not careful you may end up chasing very strange bugs in your code. That said, if you do go for the second option, be sure to at least add some diagnostics logging to it, so that you can see what it does when you’re not watching.