Introducing MemBus: Constructing it

as you might have guessed, MemBus isn’t a single class. A number of different responsibilities are tucked nicely behind the IBus interface. Those responsibilities want to be configured, which is done through the BusSetup class.

The BusSetup either takes a class that interacts with, or it allows you to interact directly with the IConfigurableBus.

Let’s talk about those responsibilities by looking at the interface:

• ConfigurePublishing: Given a Message and a number of subscriptions, configure how the message is published on the subscriptions
• ConfigureSubscribing: Given a subscription, configure how those subscriptions are shaped when a message is to be published to them
• ConfigureBubbling: Given a Bus, which may be a child or a parent of some other bus (the concept will be explained in a later post), configures if messages bubble up to a parent or are pushed down to a child
• AddResolver: A subscription resolver’s job is to provide subscriptions for a given message
• AddSubscription: Pretty clear thing.
• AddAutomaton: An automaton can be anything whose lifetime should be closely related to the Bus.
• AddService: Similar to an automaton, these are rather instances that serve some purpose in making other parts of the Bus work.

MemBus doesn’t provide you with any singleton or anything. Being essentially a service to your application, it is your responsibility to keep as many instances of IBus as long as you want, although it is likely that you’ll usually have one instance around.