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):
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.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I guess I can take i one step further with more lambdas.
Will be nice to get rid of all “magic” strings.
Try add expressions and static reflection, it may be better…
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!!!
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….?
i am just trying some tricks,
Component.For()() .Subscribers(Subscriber.ForComponent
(“subscriberId”,(x, y) => x.ServiceStarted += y.Subscriber));
.ImplementedBy
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.
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?
c)?
Thanks, Brad
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.
Nevermind… reading the referenced “forgottenskies” link:
)