Some people and organizations prefer to do feature toggles rather than branching by feature in their source control system. Regardless of your opinion on which way is best, this post will demonstrate a “fubu way” of doing feature toggles.
Here is a list of the goals we would like to accomplish to setup feature toggles.
- Specify features in web.config via AppSettings (although other options should be possible)
- Make an extension point in a page for which to expose pluggable features
- Avoid feature coupling as much as possible
- If possible, avoid runtime conditions when rendering page for feature area
We are going to leverage a bottle called FubuMVC.ContentExtensions, so start with installing this extra nuget.
Then let’s setup our page to look like the following.
The WriteExtensions method is what will accomplish goal #2. The named area is optional, but allows you to expose various other extension points if necessary.
Now let’s setup the infrastructure for our extensions. Add the following code to your project.
The interesting piece here is in the FeatureActivator. I’ve added a couple different pluggable features to demonstrate different ways you can render content through the ContentExtensions. Jeremy has a post on some of the finer details here. Another subtle detail is that the conditions for rendering features is done while bootstrapping instead of at runtime accomplishing #4 of our goals.
Last let’s deal with the AppSettings. I’m going to leverage a bit of StructureMap magic stolen from my co-workers here to eliminate some of the coupling to AppSettings directly, but as you can see this is pretty flexible so feel free to plug in your own way of doing things.
With that you should now be able to render the page and play with the values in the config file to see the features appear and disappear.
FubuMVC’s modularity story really makes this type of thing nice. I’ve seen others do this in different frameworks, but usually the result is coupled features and boolean values that get passed around through all the various layers of your application and the final condition ends up being placed inside the view. Unfortunately this makes testing even harder. Testing this for the most part would only be testing the FeatureActivator and some service registrations.
In the future ContentExtensions won’t require extending only a IFubuPage<TModel> page. They will allow for a regular IFubuPage, and we may create extension points inside the view engines for content areas or sections in Razor so that ContentExtensions can fulfill that content as well.
I hope this post gives you some ideas and shows some of the benefits FubuMVC brings with regard to doing feature toggles.