Lessons learned from the IoC framework comparison.

In the previous posts I compared a few IoC frameworks.

It was an interesting journey to write the prototypes, then the posts one by one. I also learned valuable lessons from comments and questions. I’m trying to summarize them below.

XML still has an advantage

XML had a big hype a couple of years ago. Now people mostly hate it. Still, it has something on its side: Using XML for DI config, it’s extremely difficult to mix configuration and code logic.

So you’ll have a declarative configuration, and that’s good. On the minus side, this configuration will be difficult to maintain. I.e. it’s hard to read and it has no compile-time checking.

You can choose this with Spring and Java EE.

Constructor injection is ugly but safe

If you have constructor injection, then you can make sure that your beans are always fully configured. So you have one less thing to test.

In an ideal world you have good unit test coverage anyway. So you can switch to setter or field injection. These big constructors are ugly. They make testing difficult too.

Again, in an ideal world, your beans are well-factored and they don’t have that many dependencies. In an ideal world you have lots of small classes and everybody in your team can deal with it. Pun intended.

You can choose this with Spring and Guice.

Java configuration provides compile-time check.

If you build your beans with java then you’ll have a strong compile check. I.e. the interfaces and the implementations will always match. Your constructors parameters will be in the right order too.

In an ideal world you have good unit tests for this. But we already covered that 🙂

On the other hand, this approach requires some discipline. Otherwise you just add a little logic here, a little there, and you have a nice spaghetti configuration. You don’t want that, I suppose.

You can choose this with Spring and Guice.

Annotations have a caveat

It’s really nice to add annotations to your code. It makes development easy because you don’t need to check the separate configuration files during development.

There is one problem though: with framework-specific annotations, like @Autowired, you build dependencies on the framework. You effectively break the Hollywood Principle.

If you’re sure you won’t replace your framework, you’ll be fine. You can enjoy how easy it is to embed metadata into your code. Otherwise you’ll need another approach.

You can choose this with Spring. It’s mandatory with Guice and Tapestry-DI.

Your insights

Did I miss something crucial? Did I bad-mouth your favorite feature? Please let me know in comments.

Advertisements

About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in programming and tagged , , , . Bookmark the permalink.

2 Responses to Lessons learned from the IoC framework comparison.

  1. Kofa says:

    By using JSR-330 javax.inject annotations (https://jcp.org/en/jsr/detail?id=330) you can reduce dependence on a particular framework. It’s supported by both Spring and Guice.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s