Using StructureMap with WCF in Azure

I currently have the luxury of starting out on a green field Azure project. Naturally you start out with the intention that this will be the project where everything is done right (let’s see how that goes) from start. Besides delivering what the customer wants, for me, done right includes well designed code, well tested code and (since we are using Azure) highly scalable code.

In this project we have a REST WCF service that will be called by devices such as WP7, iPhone and Android phones. This service is then used to create users and then persist them into Azure Table Storage. In order to fulfill my “done right” criteria I want to be able to inject dependencies into the constructors of the WCF services to make them easier to test. I also would like to delegate the instantiation work to StructureMap. To set all of this up we’ll have to

  1. Implement our own IInstanceProvider
  2. Implement our own IServiceBehaviour
  3. Override WebServiceHost
  4. Override WebServiceHostFactory
  5. Make sure that our WCF service use our own WebServiceHostFactory
  6. Register our dependencies in StructureMap
  7. Taste the glory

I realize that it looks to be a lot of work, but the implementations really are straight forward and easy to follow. Basically, our end goal is to have our WCF service look something like this.

By injecting an IUserRepository directly in the constructor we can easily test this class using mocking tools such as Rhino Mocks. Now, to be able to write our services like this we need to do two things. First we need replace the factories instantiating our UserService so that we can create them using constructors taking parameters. Secondly, we need to make sure that our implementation of IUserRepository is registered in StructureMap.

Before we start I would like to mention that I had a lot of help from both Jimmy Bogard’s post and PlanB Software’s post (thanks for you help!).

Create our own WCF instances

In order to create our own WCF instances we need to implement our own IInstanceProvider. This will allow us to create our instances using StructureMap.

As you can see, in GetInstance(…), we call StructureMap’s ObjectFactory to create the instance for us. Now we have to tell WCF to actually use our own InstanceProvider instead of the default. In order to do that we need to implement IServiceBehaviour.

Here we make sure that we use our own StructureMapInstanceProvider for each endpoint. Now it’s time to add this behavior to our WCF service. First, we will override the default WebServiceHost.

In OnOpening() we make sure that we add our own StructureMapServiceBehavior. In order to have WCF use our StructureMapWebServiceHost we also need to override WebServiceHostFactory.

Finally, since this is a REST WCF Service, we add in our Global.asax.cs. As you can see we also specifies that it should use our StructureMapWebServiceHostFactory.

That’s it! We have replaced the default WCF instantiation with our own. Now to the next part, register our IUserRepository in StructureMap.

Register types in StructureMap

First of all, let’s take a look at the implementation of IUserRepostory.

As you can see we take a UserServiceContext as a parameter in the constructor. This is our way into Azure Table Storage. Since we don’t inject a interface in the constructor, this class will be quite hard to test. So we’ll try to keep this class as simple and without logic as much as possible.

Since the WCF Service runs in an Azure WebRole, my first thought was to initialize the ObjectFactory in the OnStart() method of the RoleEntryPoint. From personal experience I can tell you that it won’t work, at least not in Azure SDK 1.3. Instead I put the initialization in Global.asax.cs Application_Start(…) method.

There is really no magic here (except the awesomeness of StructureMap). We let StructureMap scan our assemblies for type to register and we specifically tell it how to create the UserServiceContext so that it can be injected into our UserRepository.

Summary

With all this in place we basically have our infrastructure completed and hopefully we only need to make few, if any changes, while developing. We only use StructureMap directly in two places so we don’t need take any special care depending on which IoC container we use. It’s simply enough to create new types and inject them into the constructors and StructureMap will find and register them as we go.

Trackbacks for this post

  1. Distributed Weekly 90 — Scott Banwart's Blog

Leave a Reply