Castle MicroKernel Fluent Event Wiring

25 January, 2009. It was a Sunday.

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 http://blogger.forgottenskies.com/?p=266):

container.Register(Component.For<PublisherClass>() .Configuration(Child.ForName(“subscribers”) .Eq( Child.ForName(“subscriber”).Eq( Attrib.ForName(“id”).Eq(“Subscriber”), Attrib.ForName(“event”).Eq(“Published”), Attrib.ForName(“handler”).Eq(“OnPublish”) ), Child.ForName(“subscriber”).Eq( Attrib.ForName(“id”).Eq(“Subscriber”), Attrib.ForName(“event”).Eq(“Published”), Attrib.ForName(“handler”).Eq(“OnPublish”) ), ) ) ); </textarea>

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

<textarea name="code">container.Register(Component.For<PublisherClass>() .Subscribers( Subscriber.ForComponent(“Subscriber”, “Published”, “OnPublish”), Subscriber.ForComponent(“Subscriber”, “Published”, “OnPublish”) ) ); </textarea>

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

<textarea name="code">public class Subscriber { public class SubscriberInfo { public string Id { get; set; } public string EventName { get; set; } public string HandlerMethodName { get; set; } } public static SubscriberInfo ForComponent(string id, string eventName, string handlerMethodName) { return new SubscriberInfo{Id = id, EventName = eventName, HandlerMethodName = handlerMethodName}; } }

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

public static class EventWiringFacilityRegistrationExtensions { public static ComponentRegistration<S> Subscribers<S>(this ComponentRegistration<S> componentRegistration, params Subscriber.SubscriberInfo[] subscribers) { var subscriberNodes = from s in subscribers select Child.ForName(“subscriber”) .Eq( Attrib.ForName(“id”).Eq(s.Id), Attrib.ForName(“event”).Eq(s.EventName), Attrib.ForName(“handler”).Eq(s.HandlerMethodName) ); var subs = Child.ForName(“subscribers”).Eq(subscriberNodes.ToArray()); return componentRegistration.AddDescriptor(new ConfigurationDescriptor<S>(subs)); } } </textarea>

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.
</S></S></S></S>

← The State of Windows Mobile

PTOM: Breaking Free from HttpContext →