java - What are Dependency Injection & Spring Framework about?

I think I can take a crack at the question, although I'm not sure that any answer will be satisfactory.

The easy answer is that Spring is combination of technologies:

1. dependency injection, which uses the Hollywood principle to help you keep interface and implementation separate;


2. aspect oriented programming, which isolates cross cutting concerns into modules that you can apply declaratively. The "hello world" of AOP is logging, but it's all over Spring (e.g. transactions, dynamic proxies for remoting, security, etc.) Think servlet filters and you'll have the idea;


3. libraries to help with common tasks like persistence (JDBC, Hibernate, iBatis, JDO, JPA, etc.), remoting (RMI, HTTP, web services), asynch messaging (message driven POJOs), validating and binding, web MVC (Spring or Struts), utilities like e-mail, scheduling, security, etc.

But the deeper answer is that you're getting the benefit of Rod Johnson's experience as a consultant on Java EE projects. He distilled what worked for him on his gigs into Interface 21/Spring, and now you can have the benefit of all that for free.

The Spring team writes code that is designed, tested, and follows standards more rigorously than anything I'll ever write. (Imagine Juergen Hoeller browbeating Rod Johnson because his code didn't meet the standard prior to check-in.) I can count on their framework code when I use it and concentrate on my business problem. I'm not writing boiler plate code again and again.

For me, Spring is more about an architectural template that acts as a guide for creating web apps. Some people might say that it's over-engineered, and for certain problems they're correct, but for the kind of problems that I'm faced with on a regular basis Spring is just the ticket.

As for the subquestions:

What advantages do we have when using dependency injection frameworks?

Objects don't have to be responsible for managing their dependencies. Spring's application context is really just a big Factory Pattern from the GoF. It encourages you to design to an interface so you can change the implementation as needed. Your persistence interface might use a JDBC implementation today, Hibernate tomorrow; you might decide to auto generate a proxy to manage its transactional behavior. None of the client code has to change if you code to an interface.

The idea of describing classes with setter values and/or constructor parameters seems strange to me. Why do that? Because we can change the properties without recompiling the
project? Is that all what we gain?

Strange? You don't use properties or constructors in your code? You do it because that's the way most Java classes are written. Spring merely uses those mechanisms as a way to provide dependencies to the class.

Then, what objects should we describe in beans.xml ? All objects or only a few ?

Only the beans that have dependencies. I still call "new" for objects that are local to a particular method. They are created, used, and garbage collected in method scope. Those need not be under Spring's control.