Yet another layer of indirection

On technology and geekiness...
Mostly .Net development

My other activities

Switching Fun

In my last post about Feature Toggles I mentioned that, for my simple scenario, I chose FeatureSwitcher amongst the plethora of packages (254 packages for the feature toggle search, never went beyond page 1).

Some Whys

I needed configuration support and it is supported by the means of another package. Check for solving my problem.

I also liked their object model to deal with configuration in code. Likeability check.

I dislike magic strings. Check for being based on types.

How did I use it?

I cannot show the real code but I can show bits of a sample project.
The project is an OWIN web site that uses Nancy and Razor to render an application with an optional feature.

Create a feature. That is a type that implements the IFeature marker interface

Set-up configuration by adding the configuration section group. In this case, have the actual features are located in separate file:

Tell FeatureSwitcher that configuration is to be used and that features are named after the type that implements the interface.

Check whether the feature is enabled and render the markup if it is.

Pushing through the last mile

When I mentioned I liked to have types instead of just strings is not only for type safety (aka intelli-sense dependency), but because we can easily attach behavior to types. So now, a feature is not only able to allow telling whether it is enabled or not, but methods can me added to perform the activation steps, for instance.

If we didn’t do anything else, the feature could be “guessed” and accessed though the URL (no, it is not as crazy as it sounds, I have had clients that demanded to scramble routes to avoid guessing from users and/or competitors. True Story). Now we can have the activation code right inside the feature and interrogate itself for its status:

So if someone gets a hold on the route, he will be greeted by the hilarious 404 status code: