问依赖注入容器的好处是什么？

EN

我理解依赖注入本身的好处。让我们以Spring为例。我还理解其他Spring特性(如AOP )、不同类型的帮助程序等的好处。我只是想知道，XML配置的好处是什么，例如：

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

与普通的旧java代码相比，例如：

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

这是更容易调试，编译时间检查，可以理解任何人谁只懂java。那么，依赖注入框架的主要目的是什么？(或者一段显示其优点的代码。)

更新：

如果

IService myService;// ...
public void doSomething() {  
  myService.fetchData();
}

如果有多个myService，那么myService框架如何猜测要注入哪个实现呢？如果给定接口只有一个实现，并且我让IoC容器自动决定使用它，那么在出现第二个实现后，它就会中断。如果有意地只有一个接口的可能实现，那么您就不需要注入它。

看到IoC的一小块配置将是非常有趣的，这显示了它的好处。我使用Spring已经有一段时间了，我不能提供这样的例子。我可以显示一行代码，这些行演示了hibernate、dwr和我使用的其他框架的优点。

更新2:

我意识到IoC配置可以在不重新编译的情况下进行更改。这真的是个好主意吗？我可以理解什么时候有人想要更改DB凭证而不重新编译-他可能不是开发人员。在您的实践中，开发人员以外的其他人多久更改一次IoC配置？我认为对于开发人员来说，并不需要重新编译特定的类，而不是改变配置。对于非开发人员，您可能希望使他的生活更轻松，并提供一些更简单的配置文件。

更新3:

接口及其具体实现之间映射的外部配置

有什么能让它伸直的？并不是所有的代码都是外部的，当然可以--只要把它放在ClassName.java.txt文件中，手动读取和编译就行了--哇，你避免了重新编译。为什么要避免编译？！

节省编码时间是因为您以声明方式提供映射，而不是在过程代码中提供映射。

我理解有时声明式方法可以节省时间。例如，我只声明一次bean属性和DB列之间的映射，hibernate在加载、保存、构建基于HSQL的SQL时使用此映射。这就是声明式方法工作的地方。对于Spring (在我的示例中)，声明有更多的行，具有与相应代码相同的表现力。如果有这样的声明比代码短的例子，我希望看到它。

控制反转原理允许简单的单元测试，因为您可以用假的实现替换实际的实现(比如用内存中的数据库替换SQL数据库)。

我确实理解控制好处的倒置(我更喜欢将这里讨论的设计模式称为依赖注入，因为IoC更一般-有很多种控制，而且我们只反转其中的一种--初始化控制)。我是在问为什么有人需要的不是一种编程语言。我肯定可以用代码用假的实现来代替真正的实现。这段代码将表示与配置相同的内容--它只会用假值初始化字段。

mary = new FakeFemale();

我理解DI的好处。我不明白与配置代码相比，外部XML配置会带来什么好处。我不认为应该避免编译--我每天都在编译，而且我还活着。我认为DI的配置是声明式方法的坏例子。如果声明只声明一次，并且多次以不同的方式使用，比如hibernate cfg，在bean属性和DB列之间的映射用于保存、加载、构建搜索查询等，则声明可能很有用。Spring DI配置可以很容易地转换为配置代码，就像在这个问题开始时一样，不是吗？它只用于bean初始化，不是吗？这意味着声明性方法不会在这里添加任何内容，对吗？

当我声明hibernate映射时，我只是给hibernate一些信息，并且它是基于hibernate工作的--我没有告诉它该做什么。如果是春天，我的声明会告诉春天该怎么做--那么为什么不直接宣布呢？

最后更新：

伙计们，很多答案都告诉我依赖注入，我知道这很好。问题在于DI配置的目的，而不是初始化代码--我倾向于认为初始化代码更短、更清晰。到目前为止，我对问题的唯一回答是，当配置发生变化时，它可以避免重新编译。我想我应该发布另一个问题，因为这对我来说是个大秘密，为什么在这种情况下应该避免编译。