One thing I did immediately is to use generics to minimize the use of strings (and you could wrap a library around an existing dependency injection framework) as well. This enables much better error handling, and some limited compiler assistance.

I hate the setter paradigm, as it means you have objects floating around that could quite possibly change at any time, so all my objects are constructor initialized.

What I found was I only wanted to think about objects in a few ways.

-1- I needed “the/a” something – ie “the” main form, “a” compressor etc etc

] ICompressor compressor = Injector[ICompressor].Get();
* note – weird syntax is because the blog doesn’t like greater than or less than signs

-2- I needed a “new” object – ie give me a new order record, or a new trade

] ITrade newTrade = Injector[ITrade].New();

-3- I needed ALL the objects implementing a particular interface – for instance all the market visualisation plugins

] IVisualiser [] visualizers = Injector[IVisualiser].All();

-4- or finally, and the one where I depart most from the traditional, is that I have the idea of a particular action for a particular object – sort of like shell verbs work – for example, each object can have a control registered to display it, but they follow the object hierarchy, so there is a display for just an “object”, and one for a trade, and one for a particular type of trade. The program picks the most specific one available..

] IDisplay theDisplay = Injector[IDisplay].For( thisTrade );

We have automated release systems, dlls released onto network drives, and in our business, even a few minutes outage could have millions of dollars worth of impact… so there is no benefit to us doing the injection from a config file. Instead, I do the injection from a single “Code” configuration file, which is compiled as the main assembly for the project. This means that even though the underlying engine is using reflection and strings, there is compile type checking on all objects that are injected – it’s impossible to have the sort of errors to which you are referring. I find it all works quite nicely, and think it’s a pretty simple paradigm.

In the specific case of Spring.NET, you can use the ObjectFactoryCreatingFactoryObject (mmm, gotta to love that name) to remove hardcoded Strings from one’s code… in the case of the OFCFO, one only specifies the lookup name once (which is a good thing). But (and there is always a but ain’t there) this comes at the price of coupling one’s code to Spring (only a simple interface, but still, one doesnlt typically want to go there).

There is another option (in addition to the approach you have taken, and the OFCFO approach) and that is encapulated by the ServiceLocatorFactoryBean. Yes, this class is a Spring Java class, but could easily be ported over to Spring.NET.

There is (yawn) yet another approach, and that is using so-called (I didn’t make these terms up, I just inherited them) Method Injection. This variant is supported by Spring.NET (and Spring) and a host of Java IoC containers. A comment on your blog is not the place to go into this variant, but the following blog entry from Rod Johnson may prove of interest.

http://blog.springframework.com/rod/?p=1

The previous commenter (Jeremy) has a valid point. Spring.NET, StructureMap, whatever … I think the main point to take away is that IoC (DI) itself rocks.

ICustomerForm form = (ICustomerForm)ObjectFactory.GetInstance(typeof(ICustomerForm));

to avoid the string dependency problem that Spring.Net causes.