Thanx. I will definitely take a look at it.

SMap has done Xml configuration from the get go. The last couple releases have ironically been about making Xml completely optional. Seriously though, for everything except real configuration items (connection strings, file paths, url’s, etc.), doing it in code is easier, less error prone, and allows for automatic refactorings better than the Xml.

You can mix and match the configuration. Xml for stuff that absolutely has to be external, and the FI DSL for everything else.

Thanks for pointing it out. I’m in the process of ditching aaaallll of our attributes.

@Bryan

Unity? No reason. I know StructureMap to be _very_ terse, and have no experience with Unity. SM has been around in production for 4 years, while Unity is new. There’s something to be said for a product several versions old.

This concept probably wouldn’t jive well with your examples (as it would be too opaque), but something that your readers may want to be aware of:

One neat thing about 2.4.9 and later is that there is the concept of convention scanners (or just ‘conventions’).

So you can actually have StructureMap look for patterns in your types and do whatever magic you can think to tell it to do. For example, one of the ones that comes with StructureMap is the DefaultConventionScanner which, if you tell SMap to use it, it will look for interfaces that have similarly-named concrete implementations. So if you have interface IFoo with a concrete implementation class Foo : IFoo, the DefaultConventionScanner will automatically wire those up for you.

In our Bootstrapper class, we have:

StructureMapConfiguration
.ScanAssemblies()
.IncludeTheCallingAssembly()
.With();