依赖注入究竟有什么好处？

把对象生成放在了XML里定义，所以换一个实现子类将会变成很简单（一般这样的对象都是实现于某种接口的），只要修改XML就可以。这样甚至可以实现对象的热插拨。
依赖注入：

依赖注入就是Spring设计思想中重要的一部分,它是指Ioc或DI,是一个重要的面向对象编程的法则来削减计算机程序的耦合问题.控制反转还有一个名字叫做依赖注入（DependencyInjection）.简称DI.
IoC亦称为“依赖倒置原理”("DependencyInversionPrinciple")。差不多所有框架都使用了“倒置注入(Fowler2004)技巧，这可说是IoC原理的一项应用。SmallTalk，C++,Java或各种.NET语言等面向对象程序语言的程序员已使用了这些原理。
应用控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用，传递给它。也可以说，依赖被注入到对象中。所以，控制反转是，关于一个对象如何获取他所依赖的对象的引用，这个责任的反转。
依赖注入(DependencyInjection)和控制反转(InversionofControl)是同一个概念。具体含义是:当某个角色(可能是一个Java实例，调用者)需要另一个角色(另一个Java实例，被调用者)的协助时，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在Spring里，创建被调用者的工作不再由调用者来完成，因此称为控制反转;创建被调用者实例的工作通常由Spring容器来完成，然后注入调用者，因此也称为依赖注入。
不管是依赖注入，还是控制反转，都说明Spring采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。在理解依赖注入之前，看如下这个问题在各种社会形态里如何解决:一个人(Java实例，调用者)需要一把斧子(Java实例，被调用者)。
(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:Java程序里的调用者自己创建被调用者。
(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。
(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。
第一种情况下，Java实例的调用者创建被调用的Java实例，必然要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合。
第二种情况下，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用。此时调用的代码面向接口编程，可以让调用者和被调用者解耦，这也是工厂模式大量使用的原因。但调用者需要自己定位工厂，调用者与特定工厂耦合在一起。
第三种情况下，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。事实上，调用者和被调用者都处于Spring的管理下，二者之间的依赖关系由Spring提供。
所谓依赖注入，是指程序运行过程中，如果需要调用另一个对象协助时，无须在代码中创建被调用者，而是依赖于外部的注入。Spring的依赖注入对调用者和被调用者几乎没有任何要求，完全支持对POJO之间依赖关系的管理。
依赖注入通常有两种:
1、设值注入。
2、构造注入。

1、分层，一般MVC框架开发，比如ssh，一般都会有service层与dao层，依赖注入可以提高层与层间，方法的重用，比如你在dao层写了一个方法，可以供service多个方法调用。
2、反射仅仅是实现了资源注入的功能，但是session控制、bean的生命周期等等等等，你不会都要自己开发吧，的确，单纯反射机制可以实现那些资源注入的功能，但Spring不仅仅是ioc与aop这两个哦。
反射机制，可能是你用到的全部，但是只是Spring的一部分而已

我发表一下我的看法.个人认为,大型框架在单纯的机制上跟反射没什么,只不过是,它整合的东西多.要做到协调性,还是需要大量研究的.所以,单纯的说机制,却是没什么高深的.如果说协调性,那不是一个人可以三天两早晨做的非常完美的.要协调资源.协调用户感受,协调处理数据关乎到其它软件的底层了.比如数据库之类的.这是我想说的.也许说的 不全,但我相信楼主明白偶滴意思.

有些东西，你没有做太得深，你没有做得足够多，说了你也体会不到，这种学术性问题真不想多说，真正的收获是实践中慢慢总结出来的。你可以想象一下和一个刚学JAVA的人说：你的代码要分层，看看他能听得进去吗

找个像样点的公司，好好工作一两年，你再回头来说服你自己，那就是真的进步了，如果你抱着一种我的观点就是对的这样的态度去看待前人的经验而不是去研究它的机制，那你只能是在绕远路。

这个符合面向对象的思想。打个比方
你需要锤子，你可以
1、自己去造。用java的话说就是调用者创建被调用者
2、你可以要找到生产锤子的工厂，向工厂购买即可。对应java的工厂模式。
3、你可以打电话找到卖锤子的商店，让人把锤子送货上门。对应spring的依赖注入

以上第1种办法，要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合
第2种办法，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用
第3种办法，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。调用者和被调用者通过spring管理。他们的关系由spring维护

你自己想想，如果拿到的锤子不是你想要的，哪个办法更方便