In StructureMap 2.5 I added the ability to make “auto registration” policies that would enable StructureMap to just scan an assembly and figure out how to register types on its own. This is yet one more example of the new trend in .Net circles for adopting “Convention over Configuration” to make our work go faster. There’ll be a backlash against that sometime soon, but for now, I think it’s a significant trend to watch play out in the .Net OSS space.
This blog post is excerpted from the online documentation as http://structuremap.sourceforge.net/ScanningAssemblies.htm. The one and only Laribee asked me to write some samples of auto registration. My respect and affection for Dave is so strong that it only took me 6 weeks to get around to it.
StructureMap 2.5+ adds the ability to do convention based type registration.
over Configuration is becoming increasingly more common as a way to reduce
the overhead of using configuration intensive tools. Type registration
conventions can be mixed and matched with explicit configuration.
The Default Convention
When using StructureMap over the last couple years I saw a lot of type
There was a reoccuring pattern. “Foo” was the default implementation of
“IFoo.” The “I” moniker is the last vestige of Hungarian Notation left in
my coding style, but it refuses to go away, so let’s just take advantage of that
naming convention with a new DefaultConvention.
Let’s say that we have a class and interface like:
To make Convention be the default type for IConvention, I can simply scan the
assembly containing these types with the new default convention:
Registering Types by Name
One of the simplest, but yet most useful, ways to use convention based auto
registration is just to add all concrete types that can be cast to a certain
PluginType and use a convention to determine the Instance name. The first
place I used this functionality was at the beginning of our MVC project.
Let’s say that we name our Controller classes like this:
As a convention, we’d like to register AddressController as the “Address” of
IController, and “Site” or IController like this:
Over 50+ Controller classes, that coding is going to get extremely tedious.
Let’s use a convention instead:
When this code is executed, we get this output:
Address is AddressController Site is SiteController
Here’s the unit test code for this functionality:
Creating and Using Your Own Convention
To write your own auto registration convention, write a concrete class that
implements the ITypeScanner interface:
Inside a custom ITypeScanner, you add types to a Container by modifying the
PluginGraph object that is passed into the TypeScanner. While having
access to the PluginGraph allows you to make any possible type of configuration
change (PluginGraph is the
behind both the Registry DSL and the Xml configuration), in practice you
probably only care about these three methods:
Here’s a sample type convention from my current project:
You apply the custom ITypeScanner by simply calling With() inside of a Scan()