As promised on the last post, this time I talk more about what I
actually implemented. Let’s start with the basic API. The whole API is
very simple and message centered. In order to be able to recieve
messages you have to implement the ISubscriber<TMessage> interface.
1 2 3 4 | |
The generic parameter TMessage specifies the type of message the subscriber is interested
in. The message should simply be implemented by a POCO. Examples could
be:
ISubscriber<ActivePatientChanged>ISubscriber<ApplicationTitleChanged>ISubscriber<CsvExportFinished>
A consumer class wants to publish messages or to register itsself for a
particular message needs to have a reference to an IMessageBus implementation.
This interface serves as a consumer side facade to the pubsub system.
1 2 3 4 5 6 | |
From a consumer perspective that’s all your need to known when dealing with publish & subscribe. Together with type inference it’s event nicer to use :-).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | |
Some other characteristics also worth mentioning:
- The current implementation captures the thread context when a subscriber is registered. All callbacks will be handled on the same thread on which they were registered.
- Only a weak reference is held to the subscriber. This guarantees that a subscriber can be garbage collected although not properly unregistered from the publish & subscribe system. The implementation detects dead references and removes them automatically.
With that beeing said I would like too conclude the series about publish & subscribe with a post about the actual implementation which will follow up …