How Windsor’s decorators can save your life (almost)

Have you ever needed some kind of “master switch” in your application – i.e. some central place to flick a bool, resulting is changed behavior in numerous places?

Recently, we got the requirement that our application could function in two modes: active and passive. In active mode, the application must work like usual, whereas in passive mode, the app must not do anything to the outside world.

In our app, doing stuff to the outside world can be two things:

  • Writing stuff to a bunch of external SCADA systems.
  • Publishing status messages via NServiceBus.

which means that in order to implement passive mode, we need to avoid doing these two things.

Now, since everything in our app is wired by Windsor, and Windsor supports the nifty decorator pattern, implementing this “master switch” was a breeze!

The master switch

First, we implemented something like this to capture the switch itself:

which is registered like this:

Note th at the switch is a singleton, thus allowing all other services to have the same instance injected. Note also that concurrency is not an issue in our system – if MasterSwitch was to be used e.g. in an ASP.NET MVC application, it would have had a couple of locks in there or something similar.

Intercepting writes to external systems

All external hardware communication goes through an implementation of this interface:

so in order to abort all writes when we’re in passive mode, we added a new implementation of IExternalStuff that looks something like this:

Note how ExternalStuffWithMasterSwitch depends on IExternalStuff – this is where Windsor gets really cool, because if I remember to register my components in the following order:

then Windsor is smart enough to resolve the ExternalStuffWithMasterSwitch supplying the next available implementation of IExternalStuff, instead of entering a cycle.

Thus, we have cancelled all writes through IExternalStuff in our entire application with a few lines of extra code.

Avoiding publishing status messages

First, we needed som way to tell if a message was a status message, which was pretty easy – now all our status messages “implement” this marker interface which in turn implements IMessage from NServiceBus:

So, in order to “swallow” all published status messages when we’re in passive mode, we implemented this decorator to IBus:

which must be registered before NServiceBus’ own IBus gets registered:

I think this is a really cool example on how wiring everything with an IoC container provides some cool hooks in an application, allowing you to modify behavior in an extremely agile and non-intrusive manner.

2 thoughts on “How Windsor’s decorators can save your life (almost)

  1. There’s good reason against mixing component registration and decorator configuration. Service overrides define which imlementation is used by a component that needs it. Registration order defines a default implementation for a service, which is a rather different concern. So, Castle’s smartness “to resolve the ExternalStuffWithMasterSwitch supplying the next available implementation” is rather error-prone.

    1. Yeah, I understand why you think that “Castle’s smartness” is rather error-prone… as always, when you have the option of either being explicit about stuff, or letting stuff happen by convention, it’s important to take into account whether the chosen solution will violate POLA… and whether a given solution is a violation, depends very much on whether this style of convention-based programming is a well-understood and accepted among your team members.

      Thanks for the comment, what the heck… great name, btw 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.