This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Careful how you inject those dependencies
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
When using dependency injection, you often find two different kinds of scenarios that are common - singleton and single-call, which match the lifetime of the objects being injected. If the object you're currently working on needs a reference to a repository, the main form, or something like that, you'll probably expose either a setter, or accept the reference in a constructor argument. This is the primary area where DI shines enabling lower levels of coupling between classes than before.
However, when your object needs to instantiate a new object at runtime the story changes slightly. For instance, you wouldn't want your UI controller to have a reference to a concrete form so that you could better test it. However, there must be some other way to inject that dependency - neither a setter or a constructor argument.
In my opinion, this is no longer DI, but rather something of a deferred object construction. Instead of your code "newing" up the concrete class, you defer that to something else, the DI framework. Indeed, all the frameworks I'm aware of support this.
One of the most common ways this construction is done is for your code to ask for the object by name. Since the DI framework needs a way to identify objects/classes for wiring purposes, every object gets a name in the config file. So, in order to get a new instance of the customer form you would write code like this:
ICustomerForm f = springContext.GetObject("CustomerForm") as ICustomerForm;
Where, in the config file, CustomerForm is defined to be a single-call object, meaning that a new instance is created every time "GetObject" is called for it.
And this works great. So you go and implement all your UI controllers similarly. In fact, any place you need to create an object, you do the same - all your programmers do. And you all pat yourselves on the back what a fantastically loosely-coupled system you've created.
Previous Topic
