Dependency Injection: why?

[Martin Bechtle]

Hello everybody. Lately I have been playing with JavaEE and Spring on Netbeans/Glassfish. Some time ago I also played with Roo and Grails which do some magic based on AOP and DI.

At first I thought it was cool... then I rapidly realized that it is a real nightmare, at least to me! I use Java because it is a static language and the main advantage is that many things can be caught at compile time instead of runtime. With dependency injection it not only happens that errors arise at runtime, they are also hard to debug! I get stacks of 5 to 8 exceptions each thrown by the other.

So I was wondering: am I missing something on DI? Is it really so cool to use instead of just having a simple factory, for example?

Let's take this:

@Inject
private Logger logger;

Why couldn't it be simply like this:

private Logger logger = Factory.getLogger();

//Factory.java:
public static Logger getLogger() { return new TxtLogger(); /* if necessary configuration goes here */ }

Why do we have to spend time configuring XML files, learning all the syntax and the properties, getting all the errors at runtime? Is there a real advantage to outsource such configuration to XML, rather than doing it inside the factory method?

Also:

MyAppContextHandler.getBean("myBeanName");

Isn't that deadly dangerous? There is no guarantee that such a bean exists!

I really don't understand why DI/IoC is used everywhere nowadays. A proper factory pattern would be a much better solution in my opinion. And by proper, I mean that errors arise at compile time:

Factory.getBean("myBean"); // HELL NO!!!

Factory.getMyBean(); // HELL YEAH!

Or am I missing something?

[William Markito Oliveira]

Well, this is an actual debate on multiple forums which doesn't only include DI but also dynamic languages vs static languages.

Since this would be a real long debate, I'd prefer to share some good literature about it and let you conclude by yourself what's best for the solution/system you'd be implementing.

"DIP in the Wild

The Dependency Inversion Principle (DIP) has been around since the early '90s, even so it seems easy to forget in the middle of solving a problem. After a few definitions, I'll present a number of applications of the DIP I've personally used on real projects so you'll have some examples from which to form your own conclusions."

- http://martinfowler.com/articles/dipInTheWild.html
- http://www.martinfowler.com/articles/injection.html

Cheers,

[Kim Haase]

You are certainly right that it is a lot easier to diagnose problems when you can catch them at compile time rather than run time.

With the Java EE platform a great deal of work involving resources has always been done at deployment time rather than compile time. Historically this involved configuring XML files (deployment descriptors). Annotations have substantially reduced the need for XML files -- unless you need to override an annotation, you can often do without a web.xml or ejb-jar.xml file entirely.

Dependency injection allows you to put off even more until deployment time -- you can wait until deployment time, for example, to specify which implementation of an interface to use.

You are right that this increased flexibility can result in a bunch of runtime errors at deployment time if a needed class isn't reachable in your application. Making your source code simpler does hide a lot of underlying complexity. I must admit that I still have trouble wrapping my mind around some aspects of Contexts and Dependency Injection for Java EE (CDI), even though I wrote those chapters (with substantial help from the spec leads and implementers).

Thanks to William for putting the discussion in a wider context, too.

[Martin Bechtle]

Thank for both replies.

Kim Haase wrote:
Dependency injection allows you to put off even more until deployment time -- you can wait until deployment time, for example, to specify which implementation of an interface to use.

Well, yes... I could imagine that with dependency injection I could have in my app a IDatabaseManager interface and then, depending on the deployment environment, decide wether to configure the app (via xml) to use a MySqlDatabaseManager implementation or a MongoDbDatabaseManager implementation, at deploy time instead of compile time.

But that's also true with Factory...

class MyFactory
{
  public IDatabaseManager getDbManager()
  {
    if (properties.getKey("dbmanager_implementation").equalsIgnoreCase("mysql"))
      return new MySqlDatabaseManager();
    else
      return new MongoDbDatabaseManager();
  }
}

And then have a config.properties file with the same kind of configuration you would do in beans.xml (and by the way, much more concise and controllable)

So I still see no real difference in term of "features" between DI and Factory for server side code execution. *Maybe* it could be handy for client-server applications, where a client must execute remote code on the server. Still, I would not use DI on a web-app framework.