One thing I noticed about Microsoft's Composite Application Guidance is that the EventAggregator class is a little inflexible. I say that because getting a particular event from the EventAggregator involves identifying the event by its type like so:
_eventAggregator.GetEvent<MyEventType>();
But what if you want different events of the same type? For example, if a developer wants to add a new event to his application of type CompositePresentationEvent<int>, he would have to create a new class that derives from CompositePresentationEvent<int> in a shared library somewhere just to keep it separate from any other events of the same type. In a large application, that's a lot of little two-line classes like the following:
public class StuffHappenedEvent : CompositePresentationEvent<int>
{}
public class OtherStuffHappenedEvent : CompositePresentationEvent<int>
{}
I don't really like that approach. It almost feels dirty to me, partially because I don't want a million two-line event classes sitting around in my infrastructure dll. What if I designed my own simple event aggregator that identified events by an event ID rather than the event type? For example, I could have an enum such as the following:
public enum EventId
{
StuffHappened,
OtherStuffHappened,
YetMoreStuffHappened
}
And my new event aggregator class could use the EventId enum (or a more general object) as a key to identify events in the following way:
_eventAggregator.GetEvent<CompositePresentationEvent<int>>(EventId.StuffHappened);
_eventAggregator.GetEvent<CompositePresentationEvent<int>>(EventId.OtherStuffHappened);
Is this good design for the long run? One thing I noticed is that this reduces type safety. In a large application, is this really as important of a concern as I think it is? Do you think there could be a better alternative design?
