Question

I realise that DI is a very flexible design pattern, although I’m struggling to accept it as my ‘silver bullet’ for creating decoupled code.

Here’s why: What happens when the dependent object has a longer lifetime than the dependencies it has been injected with?

Example application: I have a BusinessLogic class which is instantiated for the lifetime of my application. This class requires a DataContext object to perform database operations. I have thefore created an abstract DataContextFactory with two implementations: StaticDataContextFactory and WebDataContextFactory. The former maintains a single DataContext for the lifetime of the application, whereas the latter will create new DataContexts for each HTTP request.

Problem in the example : As you can see, all will be fine when the StaticDataContextFactory is used. However, when the WebDataContextFactory is used the BusinessLogic will fail, since it’s injected with a DataContext which will expire/dispose once the first request completes.

My question is: Must all dependent objects have a lifetime which is less or equal to the lifetime of its dependencies? If so, then what happens when the lifetime of each dependency is unknown to the code which instantiates the dependent classes?

Answer 1

The Spring framework’s web integration addresses this problem using proxies and aspects. Longer-scoped objects are injected with proxies to the shorter-scoped objects. Each proxy knows how to fetch the “current” version of its shorter-scoped delegate, via the HTTP session or HTTP request (for session- and request-scoped beans, respectively).

See http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-factory-scopes-other-injection