One of the things I don't like about schedule-driven projects is that whenever I spot a need for a bit of framework development I never seem to have the time to do anything about it. I had such a moment on the last project I worked on. I needed to connect two independent controls via an event, but I didn't want the controls to know anything about each other. I also didn't want the web page the controls lived on to know anything about the controls or the event they were sharing. Unfortunately, because of schedule constraints, I had to explicitly connect the controls through the parent web page in order to meet my deliverable date. My approach worked, but I'm just O/C enough about software quality to be bothered by what I consider to be a sub-standard solution with my name on it. 
What I would have liked to have done was use Microsoft's event broker from the CAB framework to connect the controls at runtime. Unfortunately the project I was on didn't already use CAB and I couldn't in conscious bring CAB into the mix right before the code was delivered - even for something as nice as an event broker. (Sigh).
So, now that my code has been delivered, and the project put to bed, I decided to take an hour or two to write an event broker for my CG.Event library - just in case I ever find myself in the same predicament down the road. I intend to blog about my event broker over the next week so stay tuned if the topic interests you.
I'll start by demonstrating (briefly) how I would like to use an event broker in a project - then I'll talk about how I put my event broker class together. Generally speaking, what I want is a way to connect one or more events on a class to one or more event handlers on another class - without actually wiring up any of the events manually. The need for this happens whenever the class with the events (the source) and the class with the handlers (the sink) don't know about each other at compile time. Because they don't know about each other they may not even know what events should be wired up to what handlers. Funky huh? An event broker solves this situation by allowing one class to "publish" events using a "topic" (which is just a string value), while allowing another class to "subscribe" to events with the same topic. The event broker listens for the events to fire (to be published) and then routes those events to the proper targets (the subscribers). It all sounds really fancy but it's really just an object that sits in the middle of the normal .NET event mechanism and directs events to handlers dynamically using string topics as "addresses".
Here is how I envision using my event broker class:
// A class with no knowledge of Class4
public class Class3
{
[EventPublication("static-test")]
public static event EventHandler Foo;
[EventPublication("object-test")]
public event EventHandler Foo2;
public static void FireFoo() { if(Foo != null) Foo(null, EventArgs.Empty); }
public void FireFoo2() { if (Foo2 != null) Foo2(null, EventArgs.Empty); }
}
// A class with no knowledge of Class3
public class Class4
{
[EventSubscription("static-test")]
public static void FooHandler(object sender, EventArgs e)
{
MessageBox.Show("See, the static event was routed through the EventBroker class!");
}
[EventSubscription("object-test")]
public void Foo2Handler(object sender, EventArgs e)
{
MessageBox.Show("See, the object event was routed through the EventBroker class!");
}
}
// A class to test the EventBroker class.
public static class EventBrokerTest
{
public static void Test()
{
// Create some test instances;
Class4 class4 = new Class4();
Class3 class3 = new Class3();
// Register the objects with the EventBroker.
EventBroker.Default.Register(class3);
EventBroker.Default.Register(class4);
// Fire the event, which should be caught and
// routed to Class4 via the EventBroker.
class3.FireFoo2();
// Fire the event, which should be caught and
// routed to Class4 via the EventBroker.
Class3.FireFoo();
}
}
In my example, Class3 and Class4 represent classes that need to be wired up dynamically at runtime. For the sake of my example, we'll say that Class3 & Class4 don't know anything about each other at compile time.
The Test method on the EventBrokerTest class first creates a couple of instances of Class3 & Class4 and then registers those objects with the event broker. I also want to support static events & handlers, so I show what that registration might look like. Once the registration is done I show the FireFoo and FireFoo2 methods being called to fire the actual events. From there, the event broker should look at the topics associated with the event and route it to the proper handler(s). How should it do that? Well, Microsoft's event broker uses an attribute for events and another attribute for handlers so I guess I'll adopt that approach. The topic string on the attribute should tell the event broker how to route events at runtime.
So how will I make this work? I'll write that up in another blog entry and post it either this weekend or next week. 'Till then go read some comics on my Cartoons tab and have a laugh or two.
See ya!