Frameworks 依赖注入框架：它们是如何工作的？ 我认为自己是一个有经验的程序员，理解依赖注入的基本概念。另一方面，我的大部分经验是编写相对低级的单人数字处理代码。我没有任何大型企业项目的工作经验

在这样的背景下，我一辈子都不明白为什么有人需要一个框架来进行依赖注入。有人能给我一个这样一个框架如何工作的简要概述，而不涉及很多细节，并解释它如何使生活比你自己的滚动更容易

---

编辑：我在这里得到了一些很好的答案。我说DI框架基本上为您提供了一种方便的方法来创建全局可访问的工厂，这些工厂在对象请求时创建/返回依赖项实例，对吗？如果是这样的话，我一直在我的代码中以非常特别的方式做这样的事情，但从未想过使用任何形式的/重量级的框架来实现它。

维基百科对好处和实现有很好的描述

我发现像Spring这样的IoC容器很有用，因为它们所做的所有其他“事情”，比如事务管理，以及它们提供的代码，比如代码模板、测试基类等等，都非常有用。此外，在Java世界中，我认为IoC是对许多开发人员认为过于笨拙的JavaEE标准的反应。正如Spring所实现的那样，IoC允许您设计POJO服务组件，在大多数情况下，我想这比JavaEE让人们跳过的障碍更容易

在某种程度上，我认为大部分（或至少部分）是精神上的自慰，这意味着容器提供的IoC优势在大多数使用容器的项目中没有得到充分利用。

---

“我们应该使用DI，因为将来我们可以很容易地交换DAO的实现，Yippeeeee”——这在我的经验中很少发生。人们之所以使用它们，是因为它们已经成为一种标准和流行语。我不是说那是件坏事；只是标准软件的IoC部分并不是使用它们的真正原因

我真的很喜欢@hvgotcodes答案，但我想补充几点，因为我是DI/IoC的忠实粉丝

我们使用DI具有以下优点：

可测试性。我们通过接口针对存储库（例如）编写单元测试。现在，对于集成测试，我们使用DI为测试注入一个“真实”的存储库。但是单元测试呢？我们不想测试“真实”的存储库/数据库。因此，我们使用DI“注入”模拟存储库。这很大程度上与界面的魔力有关（当然，您可以“硬编码”您的测试，以便在需要时使用假存储库）

中心注射点。-AKA注册表。每个项目/模块都有一个注册表，我们可以在其中打开/关闭组件。例如，在我们的测试项目中，当“某物”请求IRepository时，我们注入一个MockRepository。在我们的服务层项目中，当“某物”请求IRepository时，我们注入EntityFrameworkRepository

出色的范围管理。这取决于DI容器（我们使用.NET的StructureMap）。但是，当您设置注册表时，您可以将对象设置为在一行中包含Singleton、HTTP上下文、ThreadLocal生命周期。这同样很好，因为您在中心位置处理对象。您的组件不知道它们的生命周期，它们可以专注于手头的工作，而不是其他

组件的单行切换。这是通过注册表实现的（第2点）。但目前我们正在使用实体框架进行持久化。关于这一点，“知道”的唯一东西是注册表。因此，如果有一天有更好的结果出现，我们所需要做的就是创建另一个IRepository实现，并在注册表中跳过一行。这在长寿命应用中非常可能。我们使用L2SQL作为我们网站的v1，现在我们使用EF作为v2。如果我们将DI与v1一起使用，则切换时间将几乎减少一半。但是所有的东西都与持久层联系在一起，所以我们基本上是从头开始重写网站

当您将许多不同的原则（如存储库、POCO、DDD、接口、N层）结合在一起时，DI/IoC的好处就会显现出来

我不会将它用于不太可能发展的小型应用程序

---

这是我的两分钱。

如果您沿着DI路线开始，很快就会有一个constrator，它为对象需要的各种依赖项提供20个参数。获取这20个参数需要获取20个其他参数来构建它们。然后，在这一切的最后（开始？），您将认识到您只是将自己与经过仔细考虑的接口的具体实现（通过调用构造函数）耦合在一起。然后，6个月后，您将添加一个新的依赖项，这要求您回溯所有现有的调用并更改它们

DI框架基本上会为您处理这些管道。通过站在您和构造函数之间，它可以查询配置（可能是XML，可能是代码），当它需要一个具体对象时，它会告诉它该怎么做

对于任何具有某种内省的语言来说，基础都非常简单（注册一个具体类型以满足一个接口，当您需要一个接口实例时，然后实例化该类型。遍历构造函数创建的图形并重复）。当您还想控制对象的生命周期时，它变得复杂了（此Logger类应仅实例化一次，然后重新使用。此DataAccessFacade应每个线程实例化一次，等等）或动态选择如何满足依赖关系。DI框架通常会提供对象创建工具（找出构造函数所需的依赖关系）以及服务