[jhartmann]

Sure you have to use it where it makes sense, but IoC containers and frameworks like Spring can really make things easier. If you have to talk to anything complex (pick your messaging poison), need to keep transactions across these items, need to run under multiple different web containers and swap out configuration you are going to have some messy code to handle all of this sort of stuff. For enterprise integration problems I will pick Spring any day. For instance I can write a complex messaging bridge between two different messaging systems using nothing but some xml configuration. The mess of doing all the JNDI lookups, getting all my XA transactions right, handling firing messages after certain things happen all can be done without explicitly putting things all over the code. The beauty of IoC containers and AOP programming is that you can mix in a well tested piece of code across all your application with minimal effort. You can mixin authentication, transaction management, request cleanup, caching, etc. without making major changes to your app.

I know there are many people here that might crucify me for the opinion but I call bullshit. They just have never had to work on something sufficiently complex where IoC and frameworks like Spring can become a huge time savings. Obviously with any tool you have to make sure you don't chainsaw off your leg, and its really stupid to do certain things with any tool. The black magick of aop and IoC can make reasoning about things a little harder, but the shear power of the tool makes solving hard problems in complex applications tractable. Try auditing transaction management in an application with 10 thousand tables written by hundreds of people of various experience levels. Or just use spring transactions and inject the well tested behavior across the entire application.