Archives

Blog Stats

Meta

Posts Tagged ‘StructureMap’

I’m a big fan of TDD/BDD and leaning on my IoC container of choice, StructureMap (SM), to sort things out at runtime. What I’m not a huge fan of is WCF. It can be a pain to work with the .config spaghetti and it will always add complexity to any design that can do without. There are places where services are warranted and in these cases WCF is usually the prescribed tool.

When working with WCF, I typically relied on Poor Man’s DI to attain a testable service implementation while adhering to WCF’s no-arg constructor requirement. I knew there were ways to DI-enable WCF, but didn’t have the time to get it setup. That changed recently and I had the opportunity to create a library that allows me to let SM manage all my service dependencies with the help of this post from Jimmy Bogard.

WCF + IoC + NHibernate

I’m also a fan of NHibernate and the Session per Request pattern. This makes things relatively easy and safe – the biggest benefit being that you let your web application open an ISession in the beginning of a request and flush and dispose of the ISession at the end of the request. The Repositories and Application Services need only be written to accept an ISession (constructor injection is my preference) and leave the plumbing to the application. Of course this requires configuring your application to manage the ISession and setting up your Container to create the required instances.

Applying this pattern to WCF is a little trickier. Where a web application can manage this from an HttpModule or the HttpApplication (Global.asax), a WCF service may not necessarily be accessed via Http or Https. In this case, we have to manage our Sessions and dependency resolution from a totally different pipeline. For this reason we change our nomenclature from Session/Request to Session/Call – as in a WCF call that could be Net.TCP, HTTP, Named Pipes or MSMQ. To achieve this, I will build on top of the WCF IoC library described above and utilize the contextual Session extension point in NHibernate and the techniques outlined by this post on the Real Fiction blog.

Two Part Series

The solutions will be laid out in 2 blog posts. The first is this one, where I’ll build on Jimmy’s example by providing a base for the WCF NHibernate Session per Call library. The second post, StructureMap + WCF + NHibernate Part 2, is where I’ll actually extend the WCF IoC library to allow for NHibernate Session management.

Extending Jimmy’s Example

First let me say, many thanks to you Jimmy for this post. I always enjoy everything Jimmy writes – he has a great writing style that I find easy to follow. If you aren’t subscribed to Los Techies, where Jimmy blogs, I highly recommend adding it to your feeds and checking out MVC 2 in Action from Manning Press.

I extended Jimmy’s solution relatively slightly. Because I knew I was going to be adding NHibernate support, I gave the WCF extension points in this library the ability to work stand alone or to be subclassed. In this way, I won’t couple services to NHibernate that only need IoC support.

Instance Provider

In WCF, an Instance Provider is a factory that is called upon to create the instance of the service class. WCF gives us the IInstanceProvider interface for creating our own Instance Provider. Nothing too magical here, but this is where we wire in SM to create our service instance by accessing it as a Service Locator. Besides the name change, this code is directly from Jimmy’s post.

Service Behaviors in WCF do exactly what the name implies – add behavior to services. In this case, we need a service behavior to tell WCF that we want to use our own IInstanceProvider implementation. The bulk of the heavy lifting is done in the ApplyDispatchBehavior method, where we set our custom IInstanceProvider to every End Point on our service.

The main difference here between my implementation and Jimmy’s is my virtual InstanceProviderCreator method used to instantiate my custom IInstanceProvider. I default to the IocInstanceProvider class shown above, but the method is virtual and can therefore be overridden by a derived Service Behavior.

Using a custom Service Host will allow us to add the IocServiceBehavior shown above into the pipeline without needing to configure it in the .config file. In my opinion, that is a major pain and adding the custom Service Host pays for itself with that feature alone.

Once again, my implementation is almost identical to Jimmy’s with the exception of the virtual ServiceBehavior getter. This allows me to derive a custom Service Hosts that may need further modifications and add them to the DI-enabled pipeline.

The Service Host Factory is responsible for creating the instance of the Service Host that will eventually put an instance of the service on the wire when it is called. A custom ServiceHostFactory is used as the starting point of our WCF call pipeline extension. To sum it up as simply as possible, it looks like this:

My implementation is once again very similar to Jimmy’s with a couple exceptions. First, I offer the virtual SvcHost property for creating an instance of a custom ServiceHost. This will again allow me to plug in a different implementation of a ServiceFactory, which I’ll utilize in my NHibernate solution. Another difference is in how I’m initializing SM. Where Jimmy shows this being done in the constructor of the ServiceHostFactory, I keep Container initialization out of the Factory and allow the application to handle it during startup.

I mentioned that I’m letting the application initialize StructureMap during application start up. I also mentioned that I stuck to the WCF pipeline to ensure that this solution would work for Net.TCP or HTTP hosted web sites. This raised the question – where is a common application startup? That answer came from this post from Matt Hall. If you are using IIS 7, you can utilize a static AppInitialize() method in the root App_Code directory. This method gets called at startup from services hosted in IIS or WAS.

A few caveats worth metioning:

The class that holds the static AppInitialize() method must have a Build Action of “content”. In other words, the class should be deployed to the server as a .cs file and not compiled into the assembly. If it is compiled, I found it wouldn’t work.

If you choose to configure StructureMap from within this method, be aware of using the TheCallingAssembly() method when telling the scan where to look for types. This won’t work here because the class is JIT compiled into its own assembly that won’t contain the other types in your service.

For these reasons, I find it preferable to create a Bootstrapper class within my Service project and simply call it’s Initialize() method from within my AppInitialize() method.

We’ve now seen how to hook WCF services up to StructureMap so that it will work with any type of hosting strategy – Net.TCP to HTTP and everything in between. We’ve also seen the extension points where we can add behavior to the IoC-enabled WCF pipeline.

In Part 2, I’ll show you how to build upon the solution provided in this post to create a second library that will utilize StructureMap and NHibernate to implement a Session per Call pattern that can be easily reused – allowing developers to focus on the requirements of the application, not the Data Access plumbing.

By now it’s probably a pretty safe assumption that any developer who’s worth their salt has at least heard of Inversion of Control (IoC) or Dependency Injection (DI), if not used it at least once. IoC as an architectural concept has many benefits, including testability and helping with Open/Closed Principle compliance. The specifics of DI have been discussed many times over, so consult your friendly neighborhood Google for more on the topic. What I’d like to talk about is the tooling that helps developers achieve IoC in their own systems. The tool is known as a Container and there are many good options to choose from in the .NET space. Top picks include Castle, StructureMap (SM), AutoFac, Ninject and even the very sad entry from Microsoft – Unity.

Why StructureMap?

I’ve had to use Unity at a current gig because it was approved and didn’t require .NET 3.5, but I’ll say right off that Unity is a very simple Container that lacks the features that make working with a Container fun. Granted, we’re using version 1.1, so I can’t speak to some of the enhancements found in 2.0.

I’ve blogged about Castle in the past, which I was using because it came standard in the S#arpArchitecture. Castle is a very good Container, but it has its downfalls. The biggest, in my opinion, is that its fluency is not very intuitive. Despite how many times I’ve used it, I can’t configure an application without looking at a previous example. It just doesn’t seem to flow and feels a bit clunky. It’s still a great tool, so I don’t want to take anything away from all the hard work that has gone into it.

Then there’s StructureMap. What can I say – SM rocks and I actually have fun using it. The fluent DSL flows easily and it is capable of doing everything I’ve ever really wanted it to. Some of my favorite, and most used features, include the default convention, the ease of adding custom conventions, registering open generics and showing what’s been configured. If you haven’t worked with it, have a look and play around with it. Like anything, it will take a bit to learn the ins and outs, but after that it’s pure joy. (NOTE: some of the doc I’m linking to is a bit out of date – the only downside to SM, however, there is plenty on CodeBetter)

Define Components

It is common practice to break different layers into separate components/assemblies/VisualStudio.Net Projects, such as Core, Data, Infrastructure, etc. It is also very common to have components shared throughout the enterprise, such as Inventory, SalesProcessing, Products, etc. This is what I’m referring to as components. Since each component may have its own unique DI requirements, configuring applications to initialize each of those components, as well as itself, can become challenging and when done incorrectly can make applications brittle.

Configuring the Application

The application, in the context of this post, refers to the actual executable – web site, Windows Form, WPF, Console, Windows Service, WCF. When using an IoC Container, the application should always have the responsibility of configuring and initializing the Container. It’s not uncommon to see some developers configuring a Container at the component level because that’s where the knowledge of the component’s dependencies exists. How would the application know about special conventions or nuances that the Container should be handling? The problem with this is the case where the application wants to leverage the Container and swap out one dependency for another.

Equally as painful is the practice of configuring all the components directly from the application. Once a developer gets everything working, the configuration is typically copied/pasted to other applications that use the same components. Now when something changes, someone has the joy of [hopefully] finding all the occurrences of the code in question and pasting a new version on top of it.

Configuring Components

So we don’t want the components to configure themselves in the Container and we don’t want to copy/paste the component configuration in all the consuming applications. How do we do it then? Well I’m glad you asked. The answer is found in StructureMap’s Registry facility.

A Registry in SM is a custom class, derived from the StructureMap.Configuration.DSL.Registry class. This is where the nuts and bolts of an SM configuration should exist. A component can have one or more registries, broken down into any sized unit that makes sense. Maybe the Inventory application has a registry for some common domain services and another for specific communication mechanisms that may vary depending on the type of application.

Here’s an example of a simple component Registry that has a couple specific needs and then relies on scanning and default conventions for the rest.

Now that our components have their own default configurations broken into one or more Registry classes, we need to get that into our Container. As previously mentioned, it is the responsibility of the application to configure and initialize the Container. This is something we generally want to happen only once. This can be accomplished by putting the code to handle the initialization of SM, NHibernate, Logging, whatever, in a BootStrapper that gets called at the application’s entry point. This can be the Global.Application_Start in a web application or inside the Program class of a console or WinForm application.

Initializing Component Registries

So how does the BootStrapper initialize SM with each component registry? With StructureMap, there are actually three common techniques.

By Type

This technique is pretty straight forward and probably suits the majority of cases. In this example, we know what the Registries are and simply add them by type to SM’s configuration during initialization.

SM also offers the ability to add a registry to the SM configuration as an instance. This comes in very handy when you have a Registry that requires an instance of some type for its own configuration.

A real-life example of this is when using an NHibernate Session/Call pattern in a StructureMap enabled WCF service (details available in this post). In this case, I want the Wcf.NHibernate registry to tell SM how it should resolve an ISession. In order for this to happen, the Registry will need an initialized ISessionFactory instance, which will be passed to it by the application’s BootStrapper. Once the registry is instantiated, just add it to the SM’s configuration.

Last but least, SM Registries can be added to the configuration via scanning. I really like SM’s ability to scan the types specified and apply common and custom conventions for type registration. I won’t go into details here, as the documentation is pretty good in this area.

During a scan, SM can be told to look for all Registry implementations and automatically add them to the configuration using the IAssemblyScanner.LookForRegistries() method. This can come in handy if you are scanning your components from your application. If you have a large number of components, it may be tempting to scan all the application’s assemblies and find registries, but be warned that this can make for a very long startup when you consider the number of types in your third party assemblies, like Log4Net, NHibernate, Castle, etc. Of course, you can always apply a convention to limit which components get scanned, but it’s definitely something to be aware of. Just put some thought into your use of IAssemblyScanner.AssembliesFromApplicationBaseDirectory() and IAssemblyScanner. AssembliesFromPath(path:string).

Using Dependency Injection/IoC is a great way to build loosely coupled, composeable applications. An IoC Container is a tool that is used to tell your application how it should compose your types by defining the “what” and the “how” of your application’s dependency resolution. StructureMap is one of many available choices of IoC Containers for .NET, but its rich feature set and intuitive fluent DSL have put it at the top of my list.

Many examples and tutorials for StructureMap show how to configure a trivial application where all the types exist within the application or from application specific components. When dealing with components that are shared across the enterprise, it is important to give every consuming application a way to configure SM with their default configuration without copying the code into every application’s startup and without putting the configuration decisions solely in the hands of the component. This can be achieved through the use of the StructureMap Registry, which can be defined as coarse or granular as required at the co