The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Spring, Inversion of Control, and Dependency Injection


We (my team and I) are making some decisions about object creation for our new application.  We're split down the middle, half of us are sold on using Spring and Dependency Injection (DI) methods, the other half prefer to use traditional class factory patterns.

I can see the appeal to using DI for object creation, but it feels like a "purist" attitude rather than a "practical" attitude; i.e., abstraction for the sake of abstraction rather than practical gain.  Defining our objects in configuration files feeks like over-engineering, adding more complexity than it does re-usability.

Unfortunately, none of us have ever actually USED this pattern before so we don't have any practical authority on the subject.  Given that this concept has been around for several years now and the controversy surrounding it has yet to settle down I'm a little cautious to adopt it.

Is anyone willing to share their advice or experience using Inversion of Control and Dependecy Injection patterns?
Josh Watson Send private email
Thursday, August 30, 2007
Martin Fowler's article is worth a read:
Friday, August 31, 2007
I must admit that I am quite fond of using Spring and Constructor Dependency Injection. However, I do find myself wondering why I couldn't replace Spring and an XML file with some Factory classes written in C# and why this would be any worse.
Arethuza Send private email
Friday, August 31, 2007
When I started to use Spring I found it saved me a bucket load of time and effort I used to use writing and configuring all those fiddly factories and bits of code to locate the stuff needed by stuff and tie everything together.

That alone made it worthwhile even before any other changes to my programming style to take better advantage of DI and the IoC way of doing things.
Friday, August 31, 2007
If you're just using the IoC/Dependency stuff, you might instead look at Google Guice:

It uses annotations + code rather than XML and is said to be much faster at startup because it's more focused. But Spring also has a slew of useful interfaces (to ORMs, JDBC, message queues, etc.) and AOP constructions via annotations (@Transactional) that make it useful for more than IoC.
Chris Winters Send private email
Friday, August 31, 2007
We've been converting a system that used references to static factory methods to Spring.  Everything becomes much more testable because not as much dependency information is hard coded.  I don't know how it would compare to a proper use of factories, however, with no singletons or statics.

Friday, August 31, 2007
The Fowler article is interesting, although it compares service locators to dependency injection rather than simple factories.

I have not as yet done anything other than playing with Spring and DI, but I have implemented variants of service locator, and it is very easy to test with stubs and mocks (and even to swap in true implementations of services dynamically, for integration style testing), as the article indicates.

That being said, service locator patterns are good for precisely what their name implies: providing plug-in implementations of specific services, typically bound to an interface.
Dan Fleet Send private email
Friday, August 31, 2007
I was on a project with a very top-heavy technology stack.  Spring and IOC were part of it.  The tech stack was so heavy it crushed the project.  We couldn't handle it.  The project was cancelled.

In our post-mortem, we all agreed that it would have been better to have more control over what was in the code.  Even though everything we were using was open source and we had access, it just greatly complicated troubleshooting.  Any one component on the stack was okay, but when Spring, Hibernate, JSF, plus a half dozen other libraries and technologies, the problems multiplied. 

That was two years ago.  Maybe it's better now.
Friday, August 31, 2007
+1 OneMist8k

I've seen a couple of projects die under the attempt to combine a number of "best of breed" frameworks.
Friday, August 31, 2007
First, the lecture of the day.

Developers wrongly put their full trust into a certain technology and / or pattern with the firm belief that they'll end up with the greatest of products just because of that. That's plain wrong.

Software development requires continuous evaluation of what is correctly constructed and what not, in other words it is a trial and error process. Trust or leap of faith have no place in this process. One has to TEST IF A PATTERN OR TECHNOLOGY WORKS.

I'm totally unsurprised when projects fail because a pattern or a technology is blindly applied across an entire system just because it is in the hype. Blindly is not the way to go. Instead, people should reason about what they're doing to the point where they have an actual understanding of their actions. The key is to UNDERSTAND BEFORE YOU DO.


Like any other pattern, IoC should be used only when needed. The case for IoC is very simple: class level dependencies must be a DAG.

The simple example:
class A <-> class B

should be replaced by:

class ARelB -> class B
class ARelB -> class A

Classes A and B do not depend on each other. ARelB resolves  the dependencies instead. Instances of A and B are injected into ARelB instances.
Dino Send private email
Friday, August 31, 2007

Friday, August 31, 2007
Directed Acyclic Graph
Dino Send private email
Friday, August 31, 2007
Simplest reason: maintenance.

 - The spring XML files become a poor-man's configuration system.  Configuration parameters are fed directly into your classes from an XML file.

 - Right now, you can split up your spring configuration among several files.  E.g. one for connecting to DBs, one for your security configuration, another for your core apps.  You can have different versions of these files for development, testing and deployment.

 - It's a lot easier to read the application's design from an XML file than strung throughout the source code. 

 - Really, why would anyone *ever* hard-code their application's design into code when they can specify it in a config file?  Especially when they don't even have to write the parser/manager for it themselves?

 - Finally, Spring's got a lot of useful software that will do plenty of useful stuff.  It's a free add-on.
Lally Singh Send private email
Saturday, September 01, 2007
They are both evil - you will run into problems either way and the other side is going say "I told you so" everytime.

But the worst thing you can do is comprise both side by using both technique - you'll deal with two evils from both side.

However, IMO, XML is lesser evil.
Saturday, September 01, 2007
I've written hand-made application assemblers a few times and felt pretty good about the results. They use pluggable  configuration readers (XML, properties, database, wiki pages, etc) and push dependencies into application classes.

I work now on another project that uses factories a lot. All the factories use static methods on one configuration reader. Tests rely on test versions of the configuration. Ick.

Spring automates the kinds of things I did by hand and seems appealing for that, but I'm not a fan of XML configuration and I don't feel enough pain in my assemblers to warrant new wiring.
Stan James Send private email
Sunday, September 02, 2007
@parent: I think the real question is whether your project needs anything *else* that Spring provides -- the MVC framework, for instance, or the DAO/ORM interface.  The purpose of DI is to support plugins.  If you're not plugging into anything, then a DI framework isn't for you.

Factories have their issues, too (hard to change without breaking stuff), but they're the simplest choice if all you need is something that will make you some objects (i.e. if you're doing the gluing instead of some framework).
Matt Brown Send private email
Monday, September 17, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz