Fork me on GitHub

Matchers

Matchers can be used to take control of the routing of events. A matcher can prevent that an event is passed to a certain subscriber.

An example of this is, that an event that can be canceled is passed to further subscribers when it is already canceled.

Or an event should only be passed to a subscriber matching a certain criteria. For example if your application monitors several instruments and for each instrument there is a monitoring view. A matcher can be used to route events from an instrument only to its corresponding monitoring view.

Global, Publisher and Subscriber Matchers

Matchers can be defined on a single publication or subscription, or globally on the event broker:

Built-in Matchers

Not already canceled Matcher

When you add the NotAlreadyCanceled subscription matcher to a subscription on an event with CancelEventArgs, the handler method will only be called by the event broker if the event is not already canceled. is only called

The matcher can be used with other types of event arguments and will try to cast it. It will however not prevent the call to the subscriber in case of other event arguments types.

Scope Matcher

Publishers and subscribers can be named by implementing the INamedItem interface. This interface provides a single property:

This allows identifying an object within the event broker whereas the publication and subscription attributes are always bound to the class.

The naming is hierarchical by using the same scheme as namespaces:

Now, a publisher can define the scope it wants to publish the event to, by defining a matcher in the publication attribute:

The first event is a global event that all subscribers can receive. The second event is only passed to subscribers that are parents or twins of the publisher. The third event is only passed to subscribers that are children or twins of the publisher.

A subscriber can define the scope it wants to receive events from accordingly:

The first subscription is a global subscription that will handle all the events passed to it. The second subscription will only be called when a parent of the subscriber is firing the event. The third subscription will only be called when a child of the subscriber is firing the event.

Twins (different objects with the same name) are handled specially. A twin is always a parent and child of its twin, and will therefore always receive all the events from its twin.

Build your own Matcher

You can implement your own matcher by implementing the IMatcher interface.

The matcher gets access to the publisher, the subscriber and the event arguments. The event broker relays the event from the publisher to the subscriber only if the matcher returns true.

If you want to access further information of the publishers and subscribers, it's best to let them implement an interface the matcher casts the publisher and subscriber to and access a property or method to get the information needed.