+972 52-548-6969
Event Broker Spiking
Just spiked a test implementation on an Event Broker (similar to the CAB), basically support for loosely coupled events / commands. Took about... 40 minutes :-)
My understanding of the functionality in the CAB is based around:
- [EventPublication], [EventSubscription]
- [CommandHandler]
As far as I can see the separation between the two is main artifical, and based on whatever this is your code or a third party. Since both rely on events as the underlying mechanism, I don't see a reason to separate them out.
Biggest issue: string equality is a bummer.
I might do a live coding screen cast, showing how it can be done. Tried it now, but it is 2:28 AM right now, and I sound like a drunk sailor. I got tired of apologizing of slipping to Hebrew, and cut the recording.
That 40 minutes mark is starting to freak me, to tell you the truth...
Comments
ooh, can't wait for this one - would love to get your perspectives on it :-).
Chris
It's interesting. Between you and Jeremy, you'll single handly build a version of CAB but is this really the point of this excercise? Is the issue is that CAB is large and unweildly and the guys that follow what P&P is pushing should look towards more lean and mean implmentations like this? Are you guys saying that the current CAB is good in concept but poor in implemenation. Just trying to figure out the intentions behind these excercises.
I, at least, am having fun. There isn't much to it otherwise.
I am saying that the CAB has a lot of good idea, but I don't like the direction that it takes. This is different than saying that I don't like the implementation.
Implementation == code, direction == overall design goals of the system. IMO, the CAB has a too intrusive approach, which makes things a lot harder to deal with for the end user.
Fun is always high on my checklist when building software, so have at it. I still don't see how CAB is intrusive so it'll be interesting to compare your end result with CAB (specifically around the pieces you implemented only) to see how intrusive either is. I personally don't see the intrusion myself.
I've implemented an Event Broker in a messaging add-in for Titan as well, which also uses string identifiers for channels. Since the rest of Titan is much more intelligent than that, I'm interested in anyone's ideas to alternatives. The real difficulty is that I want to be able to set up the pubs and subs declaratively via attributes, and you can't get much more intelligence in attributes other than constants...
I'm not familiar with event brokers. Is this something similar to the Event Bus pattern?
This is basically an event registry, you can register to an event, and something else can invoke it.
The idea is that I can register to "Customer-Added" event, and someone else can raise it. This is limited to a single app model, since the underlying model is .Net events, basically.
Is it different from the Castle's event wiring facility?
Ah, cool. That's more Event bus really. The event bus catches the events and dispatches it using some interesting logic, and possibly filters. Very useful for desktop applications!
Two things I"m curious about. First, why do you say the last example (CustomerAdded event) is a bad example? Second, if you don't like string equality then why not use real objects, much like how Rhino does mocking (way better than how NMock2 did wtih it's string method and object names). I mean, if you're setting out to build a similar mousetrap that's simpler then the CAB implementation, why not build a better one for the same cost (okay, using objects and maybe reflection is n+ more effort than comparing strings, but I don't think it's a huge effort is it?)
Actually, I meant the business concerns in the sample itself is not a good example.
About strings, that is an issue that I have to take with the CLR team. Attributes can accept a limited number of parameter types. Basically int, long, string and System.Type. This limits the ability to do anything really interesting with attributes.
Ahh, wasn't aware of the implemenation. Good to know. And 3.5 doesn't address this? Pity.
No, 3.5 doesn't address that, a huge pity.
Comment preview