Roman has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Which Features of Dependency Injection Really Matter

12.10.2008
| 5387 views |
  • submit to reddit

I've spent last four years on developing applications that was build on top of the Inversion of Control pattern. My experience with IoC or more precisely Dependency Injection is biased by using of Spring framework, but it doesn't matter because features I'll be talking later coming from real application use cases.

Feature: delegated instantiation of a managed object

Why: In some cases IoC container has to be able delegate instantiation of a managed object to some else. An object model may introduce some kind of Factory or Factory method and IoC container should respect it. There are situation when the code cannot be refactored e.g. 3rd party libraries, legacy code.

Feature: collecting of managed objects

Why: Need for reducing tightly coupling between API provider and API consumer. This is useful in situation when an API defines an extension/integration point and implementations are collected in runtime based on classpath. See following self-descriptive code as example of intended feature.

public interface ServiceProvider {
}

@Service
public class MyProviderA implements ServiceProvider {
}

@Service
public class MyProviderA implements ServiceProvider {
}

@Service
public class ServiceProviderRegistry {
   @Autowired
   private List providers   

} 

public class ServiceProviderRegistryTest {
    @Autowired
    private ServiceProviderRegistry registry;

    @Test
    public void test() {
        assertThat(registry.getProviders().size(), is(2));
    }
}

Feature: visibility scopes

Why: Not all managed objects are public in terms of visibility for others. Let suppose there is a component solving some business case. This component internally uses dependency injection, but only one central facade is exposed for participation in DI to other, internally managed objects are not visible for DI outside of component. It's like something between Java visibility modificators and exposing some service in OSGi, but on level of DI. Spring framework support it by concept of hierarchical bean factories and inner beans.

Feature: adaptable dependency resolving

Why: The code runs in different environments (server, tests, local/desktop), but the dependencies are same. Lets take the datasource abstraction as an example. The code depends on datasource (javax.sql.Datasource), so there are various configuration for environments (e.g. JNDI lookup in application server). IoC container is parameterized (programaticcaly or via system properties) by target environment. According to target environment an appropriate datasource definition is taken.

Conclusion

I got constant feeling that DI introduced in EJB 3.1 still lacks these features. I don't know if it's only my opinion, but there should be one specialized JSR that brings definitely DI to Java SE. Related JSRs in Java EE should only adopt/integrate DI to application server environment.

Published at DZone with permission of its author, Roman Pichlik.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabio Kung replied on Wed, 2008/12/10 - 8:31am

There's a specialized JSR for IoC/DI. It's called WebBeans.

(I know, it should have a better name)

Roman Pichlik replied on Wed, 2008/12/10 - 10:24am in response to: Fabio Kung

Correct me if I'm wrong, but WebBeans fills the gap between component model of business layer and component model of web layer. You can easily use a EJB bean in JSF and vice versa, but what i'm talking about is using of DI as model for coupling of business logic without any dependency to web layer e.g. servlet context.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.