StructureMap usefulness

Yet again I find myself spending literally minutes of my life trying to figure out why something is going wrong, only to find a useful feature of something that could potentially save many more minutes; time better spent writing unit tests, for example, or lolling around the coffee shop talking about stuff.

Turns out in the end I'd configured the wrong repository name. Dumbass mistake of the kind we all make from time to time, but one of those cases where the wood is clouding the view of the trees in the way woods always seem to.

I'd done this ..

instead of this..

Note "EmployeeRepository" instead of "LookupRepository". For clarification, LookupRepository wasn't yet finished.

Upon trying to resolve a reference to IEmployeeService, StructureMap was throwing Exception code 202 - "No Default Instance defined for PluginFamily IEmployeeRepository". Confusing at first, turns out I was of course staring at the obvious problem all along.

Trying to replicate this was a pain as it was a case of fire up unit test; get to point that fails; fail (repeat).

Now I'm sure you've come across the ObjectFactory's "WhatDoIHave" method - which dumps out the state of the container, and what resolves to what. It's a useful way of pinpointing anything that doesn't have a concrete type defined for resolution. However, this chap is even more useful: -

Rather than having to get to the GetInstance method of StructureMap to find out you have a configuration problem, you can instead call this after ObjectFactory.Initialize, and it'll run through the map and attempt to construct everything it can.

I wouldn't recommend this for production release, but while in build it could save you at least one cup of coffee. And that's a good thing.

StructureMap is great. So much nicer to use than Unity. Feeling the love :o)