Link Details

While I strongly disapprove with the article's point of view, I'll give my up-vote ;-)

People use Spring so that they can put it on their resume (recruiters love buzz words). Spring often makes simple things complicated as demonstrated with Spring DI.

>> makes simple things complicated as demonstrated with Spring DI.

Ha ha ha ha *wipes tears from eyes* ha ha ha ha.....

Agree that ServiceLocator is a viable pattern.
Totally disagree that it requires less configuration.

Definitely requires less XML files, that's for sure ;D. And I think that instantiating directly a a class is bound to be more straightforward than telling a piece of code how it should do it itself.

The point is that:
- the configuration can be code-based, which in my point of view is positive. If you use code-based configuration with DI you get an awful lot of callls just to provide the logger, the error display service, the bussiness/DAO layer reference, etc. to all the components. And that's a LOT more configuration.
- doesn't require an external framework, nor learn the XML format and the ins and outs of Spring classes.
- is really easy to debug. The contents of the Service Locator are what you put in it, not what the Spring container thinks they should.

I wouldn't say that this approach will be valid for everyone, nor everytime. It's obvious that Spring provides a lot more things out-of-the-box. But the intention of this article was to remark that if you don't need all the bells and whistles, there are less complex approaches, which deserve being considered. There are no golden bullets. A HashMap isn't (though it's pretty useful ;D). Neither is Spring.

What's a stupid entry... Not only it's not clear about facts (spring *Can* be used as a DI only, just put spring-core.jar in Your app, spring can be used with Annotations, without single line of XML even, etc.) - but whole idea to complain that Spring isn't DI only, but complete *framework* is ridiculous... Why use cars if we have Our legs 'at hand'?...

Because I wouldn't use my car to go across the street to buy the newspaper.

And apart of the configuration subject, the creation of components to be used with DI may be harder if they have a lot of classes and a significant number of them require a reference to a service. Either you make micro-components (more configuration) or you start chaining setters from the façade to the class that needs the reference.

I do know that Spring can be used as DI container only. But people has spent ages complaining about the complexity of the J2EE spec. You can use only Session EJBs as façades to POJOs behind them, and manage transactions yourself. That is no complex at all. What everybody complains about are the transaction management, the database mapping of Entity Beans, etc. So why all the fuss in that case?

And anyway, even as just the container, Spring is a framework. Yo have to learn the XML/annotations format. Yo have to know how to specify when an object has to be instantiated as a Singleton or not. You have to define the scope of each object. When you have to learn so many things, I'd be ready to call it a framework. And, well, they call themselves "Spring Framework"!!

@eutrilla>I think you mis understood the framework thing ... It's not wether Spring is a framework or not, but to say that it is a huge framework, while actually Spring is a modular set of components, so you can use the DI part only and drop the JDBC, web, ORM parts.

And now that it has enough visibility, I happily changed my vote from UP to DOWN, to match my POV ;-)

Well, I didn't expect everyone to agree with my point of view. I just wanted to make visible a solution that I had used in the past and that had worked well for my needs.

It's clearly not better than DI in all cases, but I think that we can agree that it is at least a valid and viable solution. In my opinion it's at least more straightforward that Spring, but I think that this is not as important as the fact that there are alternatives.

Those of you that know Spring well and have jumped to its defence have made good points, indeed. And the very first sentence of the article is that I consider that Spring is a terrific piece of software. But I think that, by integrating so much functionality and due to its popularity, it is becoming dangerously close to an architectural golden bullet. I might be wrong, but my guess is that many developers start to use Spring without ever thinking about whether it is the best option for them, just because right now it is popular. If it were only because of the benefit of DI, I guess that there would be more job offers requiring programmers with knowledge on Guice. And a quick search in Indeed.com about it returns 11 entries for Guice against the almost 4000 entries of Spring framework. I'd bet something that not all those 4000 job offers use AOP and the other niceties shipped with Spring, so they COULD have chosen another option.

For some reason I don't feel comfortable with the idea that a certain tool, language, pattern, whatever is the best solution in all cases. Because of that, I think that it is possitive to know that there are always other alternatives, with tradeoffs in complexity, functionality, maintainability, cost, support, etc., so that if you choose to use the mainstream solution, you do it because you do know that it is the best option. It usually is, otherwise it wouldn't be so popular. But not in all cases. You know, KISS if you can ;D.