Castle MicroKernel Fluent Event Wiring

The Castle MicroKernel Registration API is also used in Windsor, and both have a facility to allow a components to subscribe to events exposed by each other. Right now, the only way to use the fluent API to configure the facility is to go right down and build the configuration nodes (taken from

This works fine, but it’s a little verbose for my liking. I’ve managed to get it down to:

Much nicer! In effect all I’ve done is abstract away the building of the configuration nodes. Firstly I have a Subscriber class:

Then the actual business end of things is the Extension method which allows me to use this:

As you can see, I’m just pulling out the data from the SubscriberInfo array and building up the configuration nodes. These are then passed to a ConfigurationDescriptor which is where the real business happens. Writing a custom descriptor would probably make for a more elegant solution, so if anyone’s got any suggestions then I’m all ears. When I work out how to write a test for this behaviour I’ll try and sort out a Castle patch.

This entry was posted in c#, microkernel, windsor. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to Castle MicroKernel Fluent Event Wiring

  1. Tuna Toksoz says:

    I guess I can take i one step further with more lambdas.

  2. Valeriu Caraulean says:

    Will be nice to get rid of all “magic” strings.
    Try add expressions and static reflection, it may be better…

  3. Tuna Toksoz says:

    There is one thing that I forgot about: events can only be used on the left of += operator and unfortunately an assignment operator cannot be part of an expresssion. Agh!!!

  4. cramsay says:

    Valeriu, I agree but as Tuna has mentioned I’m not sure if that would be possible in this context. If someone can point us in the right direction….?

  5. Tuna Toksoz says:

    i am just trying some tricks,

    .ImplementedBy () .Subscribers(Subscriber.ForComponent (“subscriberId”,(x, y) => x.ServiceStarted += y.Subscriber));

    This is possible since I’m using lambda’s as delegates. I think i can process it to get the right stuff: which subscribed to what but this ForComponent part disturbs me as it is not necessary.

  6. Brad Mead says:

    OT: @Colin

    Just few a questions in regard to the class encapsulation where Subscriber encapsulates SubscriberInfo. I typically warn myself off of usage like this because I don’t understand the qualities.

    Is this implementation:
    a) a pattern of which I am unaware
    b) Does it afford quality to the container or the fluency framework?

    Thanks, Brad

  7. Brad Mead says:

    Or is the Subscriber->SubscriberInfo relationship “grease” for the extension method/ linq usage? Like a thin object graph

    i.e. Child.ForName(“subscriber”) roughly equates to “give me child of the one named subscriber (SubscriberInfo?)

    Are Child.ForName, .Eq, Attrib.ForName MicroKernel Registration API extension methods?

    Sorry about the dumb questions. I am deciding on IoC containers and evaluating code-based configuration paradigms. I think I understand how to leverage your approach on down the road – I thought I might as well poke the unknowns. I am also a little linq-naive.

  8. Brad Mead says:

    Nevermind… reading the referenced “forgottenskies” link: :) )