Martin Fowler's article on dependency injection summarizes the choices between a service locator and dependency injection:

The important difference between the two patterns is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

Inversion of control is hard to understand, especially in a code base that you are wading through and not intimately familiar with. It does not help that IDEs such as eclipse are still not quite up to snuff on recognizing IoC and DI. Fowler writes:

Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

In my experience, dependency injection in spring just feels like more and more configuration, something that Tomcat used to have in spades and has slowly been decreasing. Setting up Tomcat 3 in comparison to Tomcat 5 is way harder because there were xml files galore in 3. Spring feels like that. When it craps out at runtime or startup, it isn't into the code you go, it is into the xml configuration which tends to be outside of the domain expertise of software developers, though most accept it quite cheerily, unless they don't fully understand spring. Fowler summarizes with:

The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application.

Then again if the code is an impenetrable blob that the end user is going to interact with in a manner that doesn't change the source code itself, the only place you are left to wire things in is in the configuration.

Rusty Elliote Harold has an amusing comment on Guice and how dependency injection contributes to code obfuscation. I agree with him, though the IDE can make the navigation of the where beans are coming in easier, for instance IntelliJ has it all over eclipse in this area, but, for spring anyway, it usually means going back and forth between xml and java code and then finding that it craps out at runtime rather than compile time which removes one of the benefits of a strongly typed compiled language. Harold writes:

I've been using Guice at my day job for the last year, and not by choice. I find it makes our code base far harder to comprehend and work with. ... As far as I've been able to see, all dependency injection does for us is make unit testing edge cases a little easier ...

We haven't been using dependency injection for unit testing, so I don't have any experience there. One of the pains of complex software systems is configuration. It is a stumbly mess where you to get things running perfectly you have to modify this, test, modify that, test, etc etc. We mainly use dependency injection in a configuration sense. Our software engineers are more comfortable working in code itself, so it is often easier just to explicitly put a reference in a class anyway as it is directly in their competency domain.

A good example of that is how developers when doing dhtml often stack their javascript with all sorts of CSS information. I have seen that in the past, and it is simply because they are more comfortable manipulating CSS from within the language of javascript than CSS itself. That is bad design, javascript shouldn't do anything more than display:none and display:"" along with changing the class attribute. However it is a good example of how software developers are more comfortable in the code itself, than in configuration. Harold continues:

One should not complexify a class's API purely to make testing easier. Testing exists to serve the model code, not the other way around. To cite the classic dependency injection example, if the only reason you pass a Clock object to a constructor instead of creating one privately inside the class is to support unit testing, then don't do it. Unit testing is no excuse for heavily coupled classes exposing their private parts and violating encapsulation. When forced to choose between good object oriented design and testability, choose good object oriented design.

We are hitting similar issues in our project. We are having to make design compromises in encapsulation simply to expose variables to automated unit testing.

I often think that many of these conventions are applied too widely, software being software and largely a young person's game, it is hopelessly exposed to software hipsterish tech fashion. DI is cool, lets make everything DI! Patterns are cool, lets never speak in plain English again, and lets make all our objects and structures adhere to the patterns in the GoF book!

I hate it when you are talking about structures and the pattern language gets in the way. For instance I was talking with a co-worker about undo which is usually expressed in the Command Pattern (and which we implemented in another system that way). However in PureMVC the command patterns are used as Controllers. And because of that we had a disconnect about what were commands and what were controllers.

I also dislike when someone is talking about software and discusses a pattern they are intimately familiar with, and I am not (the GoF book has 22 patterns in it), and I think, "Oh man, don't make me go and look up a book to work out what we are talking about." I keep the GoF book on top of my powermac, I am the only one in the office that does that, and I use it as a reference when other people throw patterns at me that I am not familiar with.

I am sure that half of all pattern discussion is done from ignorance, or with the one talking about the pattern not being absolutely certain what it actually is; "We should put an Observer in here, or a Visitor, maybe a Cromulator and Confabulator would be better!"

There is a reason that every software interview asks about singletons. It is the only one simple enough to remember off the top of your head. Also, because of that, I think singleton is hopelessly over-used in software simply because it is the simplest pattern structure, just one object, that a developer can use. As a result good Object Oriented structures are often littered with getInstance() or even static create() methods.

I don't know. There is a time and place, and all those folkisms, is probably a good summary for what I have written above. Use in moderation and without an eye to fashion or doctrine. Disclaimer, disclaimer ...