In the previous post I started with an overview of the problem and what sort of problem event aggregators solve. I will start with what I call simple event aggregator. Actually, it doesn’t fully comply to event aggregator pattern, however the objective is to understand the mechanics of event aggregators and how loosely coupled communication amongst modules is done. Moreover, it will set the a base for the next post. SimpleEventAggregator has 3 public methods; subscribe(), publish(), and unsubscribe(). The subscribe and unsubscribe methods signatures take an anonymous lambda expression function that takes a string (payload type) and returns void. The publish() method takes a payload and pushes it into the observable source which will take care of notifying the subscribers (observers in Rx terminology).


The dashboard.module is the publisher of the messages whenever a user clicks on the demo buttons.


All Together

Demo app source code.



I guess you already can spot the limitations of this implementation. For instance, it can only know about one event and one data type of the payload. If for example a second event with different payload type is required you would have to create a new implementation of the SimpleEventAggregator. The new implementation will differ in the name the class e.g. ButtonClickedSimpleEventAggregator, where its internal fields e.g. method signature, observable, etc. support the new data type. As you can see tell is not DRY enough, and in the next post we will try to dry it out.