16 Nov

Chain of Responsibility Using Castle Windsor and a First Experience With StructureMap – Part 1

A couple of months ago, I applied the Chain of Responsibility pattern for the very first time. I’ve never encountered a scenario before where applying this pattern would be a valid option. But now, after some refactoring, I somehow naturally ended up applying this rarely used design pattern. Lets dive into some code, shall we?

public interface IProcessor { IProcessor Successor { get; set; } void Process(Request request); } public abstract class BaseProcessor : IProcessor { public IProcessor Successor { get; set; } public void Process(Request request) { // Some base class behaviour FurtherProcess(request); if(null != Successor) { Successor.Process(request); } } protected abstract void FurtherProcess(Request request); }

This is the base class for all processor classes (bad naming, huh?) . If there is a follow-up processor available, then its Process method is called. The processor classes can now focus on their main responsibility:

public class Processor1 : BaseProcessor { protected override void FurtherProcess(Request request) { // Do something usefull } }

I’m using Castle Windsor to chain together the different processors in the particular order that I want. This involves setter injection for the Successor property. Although I’m not a huge fan of setter injection, in this case it seems like a viable option. The following example uses the fluent interface of Castle Windsor for configuring the container:

_container.Register( Component.For<ProcessorConsumer1>() .Named("ProcessorConsumer1") .Parameters(Parameter.ForKey("processor") .Eq("${Processor1}")), Component.For<IProcessor>() .Named("Processor1") .ImplementedBy<Processor1>() .Parameters(Parameter.ForKey("Successor") .Eq("${Processor2}")), Component.For<IProcessor>() .Named("Processor2") .ImplementedBy<Processor2>());

Nothing much to it. The ProcessConsumer class simply gets the first processor injected through its constructor. The above configuration results in the following chain:

ProcessConsumer1 -> Processor1 -> Processor2

Everything is fine and dandy so far. Now suppose that I want to add another ProcessConsumer that requires a slightly enhanced chain of processors like so:

ProcessConsumer1 -> Processor1 -> Processor2

ProcessConsumer2 -> Processor3 ->? Processor1 -> Processor2

This is how the configuration of Castle Windsor now looks like:

_container.Register( Component.For<ProcessorConsumer1>() .Named("ProcessorConsumer1") .Parameters(Parameter.ForKey("processor") .Eq("${Processor1}")), Component.For<ProcessorConsumer2>() .Named("ProcessorConsumer2") .Parameters(Parameter.ForKey("processor") .Eq("${Processor3}")), Component.For<IProcessor>() .Named("Processor1") .ImplementedBy<Processor1>() .Parameters(Parameter.ForKey("Successor") .Eq("${Processor2}")), Component.For<IProcessor>() .Named("Processor2") .ImplementedBy<Processor2>(), Component.For<IProcessor>() .Named("Processor3") .ImplementedBy<Processor3>() .Parameters(Parameter.ForKey("Successor") .Eq("${Processor1}")));

With this particular configuration, Castle Windsor now throws an exception with the following description:

A cycle was detected when trying to resolve a dependency.

After some investigation it seems that Castle Windsor wants to set the Successor property of Processor2 with the instance of? Processor1, which is not what I had in mind. The Successor property of Processor2 should remain empty. I believe this has something to do with the approach that Castle Windsor is taking to never inject a null reference, although I’m not completely sure.

Anyway, I got around this issue by splitting up the IProcessor interface and the BaseProcessor class as outlined in my next post.

3 thoughts on “Chain of Responsibility Using Castle Windsor and a First Experience With StructureMap – Part 1

Comments are closed.